›_ Codex Issues
Codex Issues / #40352

[Windows][26.818.5345.0] openTabs succeeds, but claimTab/tabs.get/tabs.new hang until browser-control reset

Open 💬 4 comments Opened Aug 24, 2026 by jiangyuShiro
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.5345.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Chrome control can enter an intermittent stale-session state where tab discovery still succeeds, but operations that establish or use interactive control never return.

Observed behavior:

  • browser.user.openTabs() succeeds and returns live Chrome tabs.
  • browser.user.claimTab(tabInfo), using the exact object returned by openTabs(), hangs until the outer execution times out and resets.
  • After reinitializing the packaged browser runtime, browser.tabs.list() can still succeed while browser.tabs.get(id) hangs.
  • In the same affected state, browser.tabs.new() may also hang.
  • Chrome remains open and the tabs remain visible. The failure occurs in the browser-control/session layer before page interaction.

The outer tool eventually reports an execution timeout and resets, but no bounded or actionable browser error is returned.

What steps can reproduce the bug?

The trigger is intermittent, but this sequence reproduced it:

  1. Use Codex Desktop on Windows with the bundled Chrome plugin and ChatGPT Chrome extension.
  2. Run a longer Chrome-control workflow that creates or claims tabs and keeps result tabs available across turns.
  3. After a browser-control execution or session reset, initialize the packaged browser client again.
  4. Run:
const tabs = await chrome.user.openTabs(); // succeeds
await chrome.user.claimTab(tabs[0]);       // hangs until outer timeout/reset
  1. Reinitialize the runtime and run:
const controlled = await chrome.tabs.list(); // succeeds
await chrome.tabs.get(controlled[0].id);      // hangs
  1. In the affected state, creating a new tab may also hang:
await chrome.tabs.new();

The key distinction is that discovery succeeds, while claim/get/new operations subsequently stop returning.

What is the expected behavior?

After openTabs() or tabs.list() returns a live tab, claimTab(), tabs.get(), and tabs.new() should return promptly.

If a previous browser session still owns a tab, or if the native pipe/backend has rotated, the call should fail within a bounded timeout with an actionable error. A failed browser-control execution should also release stale session ownership automatically so later operations are not blocked.

Additional information

Environment:

  • Windows 11 Home Chinese, x64, build 26200
  • Codex App: 26.818.5345.0
  • Bundled Chrome plugin: 26.818.41705
  • ChatGPT Chrome extension: 1.2.27268.51612
  • Google Chrome: 151.0.7922.170
  • Chrome profile: Default

All packaged diagnostics passed:

  • Chrome was running.
  • The extension was installed and enabled.
  • The native host manifest was present and valid.
  • The registry manifest path and expected extension origins were valid.

Temporary recovery:

Fully quitting both Codex and Chrome, then reopening them, cleared the condition. After restart, tabs.new(), navigation to an HTTPS page, and domSnapshot() all worked again.

Possibly related reports:

  • #37399: openTabs() succeeds but claimTab() hangs on macOS
  • #34472: stale browser-session ownership and DOM timeouts
  • #31706: discovery succeeds but claim/get/new-tab workflows fail

This is a current Windows reproduction on the 26.818 app/plugin generation.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #39766
  • #40243

Powered by Codex Action

jiangyuShiro · 1 day ago

Still reproducible on a newer Windows app build.

Environment:

  • Codex App: 26.820.7780.0
  • Bundled Chrome plugin: 26.820.60940
  • Windows 11 x64

Observed on August 26, 2026:

  • A Chrome tab remained visibly open, but browser control lost its controlled-tab state.
  • A follow-up operation failed with: Tab not found: <tab-id>. Existing tabs: none.
  • In the same workflow, a previously discoverable external Chrome tab became stale and claimTab() did not return promptly.
  • Creating and using a fresh managed tab restored control temporarily.

This is not byte-for-byte identical to the original failure: the newer build can now return a bounded Tab not found error instead of only hanging. However, the visible Chrome state and the controller's tab state still diverge, so the stale-session/control-state issue does not appear fully resolved.

Additional recovery observation:

  • Chrome was not restarted.
  • In a later fresh browser-control session, openTabs() returned the current live tab and claimTab() succeeded immediately when passed that exact newly returned tab object.
  • This transient recovery does not indicate that the bug is fixed. It suggests the stale ownership/binding can be released or rebuilt between control sessions, which also makes the failure intermittent.
jiangyuShiro · 1 day ago

Additional local diagnostics from the same August 26 reproduction:

Timeline (local time, UTC+8):

  • 19:51:52 — the file chooser wait timed out after 3.09 seconds.
  • 19:52:06 — a second file chooser attempt produced an unhandled timeout rejection and reset the browser-control execution environment.
  • 19:52:16 — the desktop logs reported No ChatGPT browser route is available for browser session <redacted> six times, while openTabs() still returned the visible Chrome tab.
  • 19:52:56 — chrome.user.claimTab(), using the exact object returned by openTabs(), timed out after 30.04 seconds and reset the execution environment.
  • Browser-use PiP content upsert also failed twice between 19:51 and 19:53.

There was also a local UI error spike during the failed-route state: 231 ResizeObserver loop completed with undelivered notifications messages were logged during 19:52, compared with 19–68 per minute during nearby minutes (19:48–19:51 and 19:53). The laptop fan increased noticeably during the repeated read/claim attempts. Historical per-process CPU data was not recorded, so the exact process responsible cannot be confirmed.

This strengthens the stale route/ownership hypothesis: discovery can still see the external tab after the control route has disappeared, and claimTab() waits until the outer timeout instead of failing promptly or rebuilding the route.

jiangyuShiro · 1 day ago

One more release/cleanup observation immediately after posting the diagnostics above:

  • After the browser task completed, the same Chrome tab remained shown as controlled.
  • Fully exiting Codex did not release the control state; Chrome still showed the tab as controlled after the Codex process was closed.
  • The user had to fully exit and restart Chrome to clear the state.
  • After Chrome restarted, openTabs() returned only the fresh new-tab page, and a new browser-control session could be established normally.

This suggests that stale ownership can persist on the Chrome extension/tab side rather than only in the Codex process. A Codex-only shutdown does not always clear it. Cleanup should explicitly release extension-owned tab state, or the extension should detect that its backend/control owner has disconnected and clear the stale state automatically.