fix: window ID becomes stale after full-page navigation — this._page not updated on CDP target recreate

[elias-didoo]

Problem

After opencli browser open followed by a full-page navigation (not a modal overlay), all subsequent CDP commands fail with No window with id.

Working cases (modal overlay URLs — no CDP target reset):

• post → x.com/compose/tweet ✅
• reply → x.com/compose/post?in_reply_to=... ✅

Broken cases (full-page navigation — triggers CDP target recreate):

• follow → x.com/{username} ❌
• like → x.com/status/... ❌
• search → x.com/explore → SPA navigation ❌
• timeline → page.evaluate on current page ❌

Root Cause

In src/browser/page.js, the goto() method:

1. Calls sendCommandFull('navigate', { url, ...this._cmdOpts() }) where this._cmdOpts() includes the stale this._page (the old/失效的 target ID)
2. The navigate action destroys the old CDP target and creates a new one
3. The new target's ID is returned in result.page, and goto() correctly saves it: this._page = result.page
4. BUT the subsequent sendCommand('exec', ...) call at line ~45 uses the same this._cmdOpts() — which still contains the old page field from before the assignment

The sendCommand('exec', ...) is made inside the if (options?.waitUntil !== 'none') block before this._page = result.page takes effect for that call, because this._cmdOpts() is evaluated before the assignment.

Even when the exec call is retried after a settle error, it still uses the old this._page.

Impact

PR #892 (retry on No window with id CDP error) was merged but did not fully fix this — it addressed the retry classification layer but not the root cause: this._page becoming stale after a full-page navigation that triggers a CDP target recreate.

Suggested Fix

The sendCommand('exec', ...) call after navigate should use the new page identity, not the old one. Options:

1. Inline the new page ID into the exec call — pass page: result.page directly instead of relying on this._cmdOpts()
2. Re-bind after navigate — call selectTab(0) or bindCurrentTab after navigate to ensure this._page is fresh
3. Don't cache page identity in goto() at all — always fetch the current active page fresh for each command (simplest, but may have performance implications)

Test Script

opencli browser open https://x.com
opencli twitter follow elonmusk  # fails: No window with id
# vs
opencli browser open https://x.com/compose/tweet
opencli twitter post "test"  # works: modal overlay, no target reset

Environment

• OpenCLI v1.7.0
• macOS
• Chrome Extension automation

[Astro-Han]

Thanks for the detailed write-up. I checked the current main branch before replying, and one part of the root-cause analysis does not line up with the code as it exists today.

In src/browser/page.ts, this._page = result.page happens before combinedOpts is built and before the follow-up exec runs, so the specific “combinedOpts captured the old page before assignment” path is not what current main is doing.

That said, the higher-level symptom still sounds plausible: after a full navigation / target recreate, a later command is still talking to a dead target.

To narrow this without guessing, can you add:

• the exact command sequence that reproduces on current main or released 1.7.0
• whether this happens only with Browser Bridge, or also with direct CDP flows
• the extension / daemon log around the failing navigation, especially the navigate response page id and the failing exec page id if you have them

With that trace, we can tell whether this is:

1. a stale page id after navigate
2. a second target swap after the first navigate returns
3. a retry path reusing the wrong target

[elias-didoo]

Thanks for the detailed feedback — you're right that my root-cause theory was incorrect. Here are the additional details you asked for.

1. Exact command sequence to reproduce on 1.7.0

opencli browser open https://x.com
opencli twitter follow elonmusk

Error on the second command (the first page.goto() inside twitter/follow.js):

Error: No window with id: 825614516.
    at sendCommandRaw (dist/src/browser/daemon-client.js:93:23)
    at async sendCommandFull (dist/src/browser/daemon-client.js:121:20)
    at async Page.goto (dist/src/browser/page.js:41:24)
    at async Object.func (clis/twitter/follow.js:18:9)

Full post: any command that triggers full-page navigation (x.com/{username}, x.com/status/...) fails with the same pattern. Commands targeting modal overlay URLs (x.com/compose/*) succeed — consistent with your theory that modal URLs don't recreate the CDP target.

2. Browser Bridge vs direct CDP

This happens with the Browser Bridge (Chrome Extension) path. I have not been able to test direct CDP, as I don't have a separate CDP endpoint set up.

3. Daemon/extension page ID trace

Unfortunately I can't get the extension's internal WebSocket logs from outside Chrome — the gateway log only shows the CLI-level exec commands, not the daemon↔extension WebSocket traffic with page IDs.

From the CLI stack trace, the failing window ID is 825614516. The navigate command in sendCommandFull at page.js:41 throws with this ID, which suggests the page field sent to the daemon references a target the extension can no longer find.

Some observations from the code:

• In sendCommandRaw (daemon-client.js), "No window with id" is classified as retryable: true (extension-transient), so it retries 4 times with 1500ms delay — all with the same stale page ID in the params
• This means the retry loop doesn't help because it re-sends the same invalid page field each attempt
• The sendCommandRaw retry is fundamentally ineffective for "dead target" errors since retrying the same params with a dead page will always fail the same way

To get the actual page ID trace, would you have a recommended way to expose the extension's internal logs? e.g. a GET /debug/logs endpoint on the daemon, or a Chrome DevTools Protocol (CDP) Log.entryAdded listener that could be surfaced?

Happy to run any specific test commands you suggest.

[Astro-Han]

I retried this locally on the latest CLI and could not reproduce it.

I tested:

opencli browser open https://x.com
opencli twitter follow elonmusk -v

and the second command completed normally.

So at this point it looks environment-specific rather than a repro that happens on every setup.

Could you help narrow it with these details:

• Chrome version
• OpenCLI extension version from chrome://extensions
• whether this still happens in a clean Chrome profile with only the OpenCLI extension enabled
• whether you have any tab/window manager extensions installed
• output of opencli doctor

If it still reproduces in a clean profile, that would make the issue much easier to isolate.

[elias-didoo]

After uninstalling all Chrome extensions, the issue is no longer reproducible. The CDP commands work correctly across full-page navigations. Closing as environment-specific.