[macOS 26.908.70816] cua.getState() times out with repeated missing IAB session-route errors

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

26.908.70816, build 9275, read from the installed application's Info.plist (not separately checked in the About dialog).
Installed bundle: ChatGPT.app, bundle identifier com.openai.codex.

What subscription do you have?

Not collected for this diagnostic report.

What platform is your computer?

macOS 26.6.2, Apple Silicon / arm64.

uname -mprs:

Darwin 25.6.0 arm64 arm

What issue are you seeing?

The desktop application's in-app browser is visible in the task UI, but browser/app inventory through mcp__cua_repl.js repeatedly fails to return. A fresh read-only diagnostic attempt on 2026-09-17 used:

await cua.getState();

With the normal 30,000 ms outer tool timeout, it returned after 30.1236 seconds:

js execution timed out; kernel reset, rerun your request

The original long-running task had also encountered this error repeatedly, including attempts with a 15,000 ms outer limit. The fresh 30-second attempt confirms this is not merely a consequence of choosing that shorter limit.

The application remains running; no application crash was observed during this diagnostic attempt.

What steps can reproduce the bug?

Observed reproduction in the affected running application; this is not yet a deterministic clean-install reproducer:

1. Have a localhost page open in the desktop in-app browser during a task.
2. Ask the agent to read the browser state / enumerate available tabs.
3. As the first CUA call, run only await cua.getState(); through mcp__cua_repl.js, with timeout_ms: 30000.
4. Observe the generic timeout and automatic JavaScript-kernel reset instead of browser inventory.

The fresh test was made from a diagnostic side conversation while the original task's browser remained open. Previous failures were in the original task itself. No tab was intentionally created, closed, navigated, or modified by the diagnostic test.

Local diagnostic evidence

Read-only inspection of the macOS desktop logs found repeated entries from browser-use-iab-api:

IAB_LIFECYCLE iab backend info request received
conversationId=<session> request=getInfo turnId=<turn>

IAB_LIFECYCLE iab backend info request failed
conversationId=<session>
errorMessage="No ChatGPT browser route is available for browser session <session>"
errorName=Error

The stack passes through ensureBrowserUseSessionRoute and getInfo in the installed desktop main bundle. Read-only inspection of that guard confirms the error is raised when ensureSessionRoute does not return true, before normal browser operation dispatch.

Important qualification: not every backend-info request failed. In the fresh attempt's log burst at 2026-09-17 03:45:53.255–03:45:53.348 UTC, for the same conversation/turn, there were:

• 15 getInfo requests received;
• 14 missing-route failures;
• 1 getInfo completed entry.

The outer inventory operation nevertheless timed out. This means the logs alone do not prove that route lookup is the only blocked component. Provider fan-out, inventory aggregation, or failure/cancellation propagation may also be involved.

For the original task's conversation ID, selected desktop logs spanning September 16–17 contained 64 received info requests, 57 missing-route failures, and 7 completions. Its recorded failures ranged from 2026-09-16 01:53:11.846 UTC to 2026-09-17 03:06:50.260 UTC. These are backend-request counts, not counts of user-visible tool calls.

Separately, browser-sidebar owner-sync entries associated with that original task's durable /local/<thread-id> route repeatedly used a transient conversationId=client-new-thread:<id>. This is a routing/identity-lifecycle clue, not proof of a specific rebinding race.

Scope checks and limits

• A fresh HTTP check of the localhost page returned 200 in approximately 6 ms. Earlier work in the original task could operate the same prototype using separate Chromium automation. These checks establish that the local web server was available; they do not rule out all desktop-specific transport or permission issues.
• No app/service restart, process termination, reinstall, permission change, configuration edit, cache deletion, or source patch was performed during this diagnosis, because other work was active.
• No specific root cause or fix has been established. This report identifies a reproducible inventory timeout and correlated missing-route errors.
• No raw logs, application/session identifiers, private URLs/query strings, project content, credentials, cookies, or browser storage are attached.

What is the expected behavior?

Browser inventory should return the available in-app browser/tab, or return a bounded, actionable error identifying the failing provider or route. A missing/stale route should not leave inventory pending until the outer tool kills the JavaScript kernel, especially after one info request has already completed.

Please trace route registration and transient-to-durable identity binding together with provider discovery, inventory aggregation, and timeout/cancellation propagation.

Related reports checked

• #43673: similar missing-route / unrecoverable browser-control symptoms on Windows.
• #43210: a more specific Windows interrupted-subagent/stale-cleanup trigger, which has not been established here.
• #45868: same macOS app build, but inventory succeeds there and subsequent AX/DOM reads hang. This report fails earlier, at cua.getState().
• #45006: external Chrome discovery timeout; this report concerns the desktop in-app browser and includes the route/error counters above.

Submitted by Codex at the affected user's explicit request, after local read-only diagnosis and minimization of the public evidence.

Start at the mcp__cua_repl.js call to cua.getState() and trace browser-use-iab-api through ensureBrowserUseSessionRoute, ensureSessionRoute, and getInfo in the desktop main bundle. Follow route registration, transient-to-durable identity binding, provider discovery, inventory aggregation, and timeout/cancellation propagation. Done means browser inventory returns the available tab or a bounded, actionable error instead of leaving the request pending until the JavaScript kernel resets.