Repository navigation
[Windows][26.818.5345.0] openTabs succeeds, but claimTab/tabs.get/tabs.new hang until browser-control reset #40352
Description
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 byopenTabs(), hangs until the outer execution times out and resets.- After reinitializing the packaged browser runtime,
browser.tabs.list()can still succeed whilebrowser.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:
- Use Codex Desktop on Windows with the bundled Chrome plugin and ChatGPT Chrome extension.
- Run a longer Chrome-control workflow that creates or claims tabs and keeps result tabs available across turns.
- After a browser-control execution or session reset, initialize the packaged browser client again.
- Run:
const tabs = await chrome.user.openTabs(); // succeeds
await chrome.user.claimTab(tabs[0]); // hangs until outer timeout/reset- Reinitialize the runtime and run:
const controlled = await chrome.tabs.list(); // succeeds
await chrome.tabs.get(controlled[0].id); // hangs- 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:
- [macOS][Chrome] openTabs succeeds but claimTab hangs until JS kernel reset #37399:
openTabs()succeeds butclaimTab()hangs on macOS - Chrome extension tabs remain locked by a stale session and DOM operations always time out #34472: stale browser-session ownership and DOM timeouts
- Codex Chrome plugin:
Browser is not availableafteropenTabs()breaksclaimTab/tabs.get/ controlled tab workflows #31706: discovery succeeds but claim/get/new-tab workflows fail
This is a current Windows reproduction on the 26.818 app/plugin generation.
Activity
github-actions commentedon Aug 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jiangyuShiro commentedon Aug 26, 2026
Still reproducible on a newer Windows app build.
Environment:
Observed on August 26, 2026:
Tab not found: <tab-id>. Existing tabs: none.claimTab()did not return promptly.This is not byte-for-byte identical to the original failure: the newer build can now return a bounded
Tab not founderror 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:
openTabs()returned the current live tab andclaimTab()succeeded immediately when passed that exact newly returned tab object.jiangyuShiro commentedon Aug 26, 2026
Additional local diagnostics from the same August 26 reproduction:
Timeline (local time, UTC+8):
No ChatGPT browser route is available for browser session <redacted>six times, whileopenTabs()still returned the visible Chrome tab.chrome.user.claimTab(), using the exact object returned byopenTabs(), timed out after 30.04 seconds and reset the execution environment.There was also a local UI error spike during the failed-route state: 231
ResizeObserver loop completed with undelivered notificationsmessages 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 commentedon Aug 26, 2026
One more release/cleanup observation immediately after posting the diagnostics above:
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.
yukiex commentedon Sep 5, 2026
Current Windows reproduction on newer builds
This is a related but slightly different manifestation of the stale per-tab browser-control state described in this issue.
Environment
26.901.5003.026.901.41123extensioniabWhat works
extension-host.exeandnode_repl.exeremain alive.Failure
One long-lived authenticated SPA tab remains visible in the discovered tab list, but claiming or using browser control for that tab fails immediately with:
No page interaction is reached after this error.
The failure is specific to the affected tab: another existing Chrome tab in the same browser session can be claimed and read normally.
Minimal comparison
Actual result:
Debugger unattached.Debugger unattachederror occurs for the fresh tab.extension-host, andnode_repldo not need to be restarted.The affected tab's provider correlation metadata is absent. However, the fresh tab also initially lacks that metadata and is still claimable and readable. This suggests that the metadata field itself is not the root cause; the stale state appears to be associated with the affected tab's per-tab debugger or browser-control session.
Expected behavior
When a discovered Chrome tab has lost its debugger attachment or browser-control session, Codex should:
The error should distinguish at least between:
This reproduction indicates that Chrome extension discovery and Native Messaging are healthy, while a single long-lived web application tab can retain stale browser-control state across continued use.
carabinshely commentedon Sep 9, 2026
P1 - Windows follow-up: a failed CDP click can follow a successfully saved edit
Feedback submitted through Codex Desktop on 2026-09-09: 01a080e7-dec1-7150-b4c2-08a3a4f3d454.
Related previous task for internal correlation:
01a07ca7-a09b-78a3-aa9e-6a1bdfd48b40.Adding concrete saved-action evidence to this existing Windows browser-control issue rather than opening another broad duplicate. This also appears related to the Chrome input-timeout report. Similar symptoms do not establish a shared root cause or prove a route race in this occurrence.
Environment: Windows x64 (PowerShell reports
Microsoft Windows NT 10.0.26200.0 x64); Codex Desktop; Chrome extension backend;mcp__cua_repl.jsfromunified-computer-use@openai-bundled. Both session headers record embedded agent0.153.4, originator Codex Desktop, source vscode. The owner subsequently supplied this exact product version text on 2026-09-09: “Powered by Codex & OWL Version 26.901.51231 — Released 5 Sept 2026”. Subscription: ChatGPT Pro. This owner-reported version is distinct from the embedded agent version above; the exact Chrome version at the incident was not captured.P1 - Two saved-action counterexamples
On 2026-09-08, two separate native GitHub PR-description updates each clicked Update comment exactly once. The tool reported failure; subsequent rendered-page readback confirmed that the new description had saved and edit mode had ended. No second save was sent.
All times below are UTC:
call_PtrGYE4P50o8VWBr4hY5nPikcall_LUpYkjgJX42TWYPISm5glDDccall_jirhqbRlnbm8iSOeH4HUIH4ucall_583AFV8oi5ngUZ2ellQUGOw9call_1wKgMFrA6MQspdbqp8AqJJLAExact first error:
The false predicate during the second readback was an agent verification mistake, not another product defect. The targeted follow-up established the actual saved state.
P1 impact: a generic tool failure is not proof that an external mutation did not happen. Blindly retrying non-idempotent actions can duplicate submissions. No duplicates were observed in this workflow because readback preceded retries. A timeout can legitimately leave an unknown outcome; the requested improvement is explicit dispatch/outcome classification and safe recovery guidance, not cross-system transactional guarantees.
P1 - Matching attachment and recovery symptoms
In the same continuation, older Chrome tabs intermittently returned
Debugger unattachedwhile a fresh tab to the same site later worked without changing permissions or reinstalling the extension. Fresh tabs initially also timed out, so creating a new tab was not a universal remedy. Examples:call_p2gkCAwfJjhis2TqBPMacdJ9- Debugger unattached.call_QoW21AaF8q7ziG1MXNDhzgfF- old queue-tab acquisition failed; a new tab was readable.call_unYEQeFpCAXhTBzaT4ZGTztd- old PR tab failed; navigation in a working task tab succeeded.Browser inventory remaining readable was insufficient to establish that the affected tab's command channel was healthy. No backend switching was used for these observations.
P2 - File-chooser deadline observation
While submitting the private support report on 2026-09-09, two chooser attempts on help.openai.com used
waitForEvent("filechooser", {timeoutMs: 10000})with immediate Promise.allSettled handlers around the chooser and click. Both clicks fulfilled; both chooser promises rejected withTimed out after 3000ms waiting for file chooser.despite the requested 10000 ms. The file input was inside the visible ChatKit iframe and accepted images/PDF. No chooser object was returned, no files were uploaded, and the kernel survived. Site behavior, iframe handling and effective timeout budgeting remain possible explanations; cause is not established.P1 - Previous-session bootstrap context is already tracked separately
The previous task timed out and reset at 2026-09-08 10:53:25.658 UTC, then initialization failed at 10:53:31.248 and again at 10:53:45.106, including after an explicit successful reset, with:
That signature is already tracked in Issue #41359. It is included only as preceding context; no missing-directory inspection or root-cause confirmation was performed in this occurrence.
Safe investigation and expected behavior
Use a disposable PR or test form: acquire the Chrome tab, open its native editor, fill a unique harmless marker, and click Update comment once. If a CDP timeout occurs, inspect the saved page before any retry. This is a field recipe, not a guaranteed deterministic reproducer; do not test it against production publishing workflows.
The detailed report and 60 selected sanitized evidence records were also sent privately to OpenAI Support, which stated that the conversation was escalated to a support specialist. Engineering receipt or a fix is not confirmed. Public content here omits business URLs, page contents, email, local paths, screenshots and raw rollouts; the Feedback ID provides the internal correlation point.
jiangyuShiro commentedon Sep 10, 2026
This issue no longer reproduces in my current setup, so I am closing it as resolved for now. I cannot yet confirm whether it might recur; if it does, I will follow up with updated reproduction details.