[Windows 26.1007.2314.0] IAB owner/tab inventory succeeds while same-turn getInfo logs report no route #53692

Summary

On Windows desktop, three existing task-scoped in-app-browser workflows remain blocked. Supported CUA browser discovery returns an IAB with the exact current persistent task ID, and a subsequent tab inventory returns an empty array. At the same time, desktop logs contain repeated current-task getInfo failures: No ChatGPT browser route is available for browser session <redacted>.

Please investigate the discrepancy and provide a supported route-health/recovery method. This report distinguishes raw runtime observations from our custom local preflight policy; it does not claim that every no-route log is fatal or that a product root cause has been proven.

Possibly related: #48360 (Windows IAB discovery/content split), #45028 (route lifecycle), and #52472 (temporary owner alias on macOS). These are related symptoms, not assumed identical causes.

Environment

• Windows 11 Home, 64-bit, OS version 10.0.26300.
• Installed Windows package: OpenAI.Codex, version 26.1007.2314.0 (read from Get-AppxPackage).
• Configured bundled browser/unified-computer-use runtime version: 26.1007.21434.
• Bundled @oai/cua package reports 0.2.6.
• Observation date: 2026-10-13, timezone Asia/Shanghai (UTC+08).
• Backend under investigation: task-scoped IAB, not a foreground Chrome/Edge extension.
• App version and browser component version are different version fields; they are not being treated as a mismatch.

Bounded reproduction in the affected existing tasks

With an already established CUA runtime and the existing task-owned binding:

1. Call cua.listBrowsers({emit:false}).
2. Read the returned IAB entry and verify metadata.codexSessionId equals the persistent task ID.
3. In a separate tool call, use that exact returned browser ID:
   cua.listTabs({browser: returnedIabId, emit:false}).
4. Correlate both calls with the same task/turn and timestamps in desktop IAB lifecycle logs.

This reproduces the inventory/log discrepancy on this machine. It is not a verified clean-install reproducer.

Representative original-task observation (UTC)

The same request windows contain 36 logged current-task no-route errors. These are 36 log records, not 36 agent retries; the agent made two public calls. In the bounded logs inspected for this turn, we did not find the exact matching backend info request completed response required by our local policy to classify all those errors as sibling-pipe noise. A later PiP metadata event reports IAB/browser ID, with tab ID undefined.

An earlier bounded owner/inventory probe in another original task showed the same broad discrepancy. Both calls returned successfully; its post-check recorded 36 no-route messages. No selected-host close was found in that checked window.

Important confounders and limits

• A custom local preflight gate consumes route logs and blocks source navigation after unresolved no-route events. Thus, in the latest bounded runs, source navigation/content reads were not attempted after the gate denied them. A local gate denial is not proof that a fresh page read would fail.
• Browser owner/inventory success also does not prove usable page control or a completed download.
• An additional task initially reused an earlier execution-turn lease. That was an assistant orchestration error; it was recorded and released, and its reads were not accepted as valid authorization. A preflight with the correct current turn still rejected the route. We are not presenting the stale-lease mistake as a product bug.
• Earlier local false-positive rules around temporary owner aliases and non-disposing activity completion were corrected. These corrections did not establish page control or restore the end-to-end workflows.
• Empty tab inventory alone is not treated as a bug. It becomes diagnostically ambiguous when accompanied by the errors above.
• Read-only inspection of the installed public inventory helper shows user-tab enumeration errors can be logged and converted to an empty list before merging with managed tabs. We have not proven that this branch ran in these particular calls.
• No controlled VPN/network A/B was completed in this latest reproduction. We cannot assign causality to VPN, source websites, log fan-out, or the proprietary routing implementation.
• No installed product runtime, authentication, permission enforcement, or application database was patched for these probes.

Impact

Two recurring spreadsheet-download/report workflows and another independent browser-dependent task remain unfinished. Local tests and browser discovery are not sufficient business acceptance. Old exports with unknown outcomes have not been blindly repeated.

Requested product-team guidance / fix

1. Can successful listBrowsers plus an empty listTabs legitimately coexist with these same-task getInfo no-route errors? Which supported signal distinguishes harmless discovery fan-out from a missing usable route?
2. Provide or document an authoritative task-bound route-health check and supported rebind/recovery procedure, without borrowing another task's browser, deleting user data, or repeatedly restarting the whole app.
3. Please investigate Windows task/owner lifecycle handling, including persistent thread IDs versus temporary client-new-thread aliases, with a regression test for multiple long-lived tasks.
4. Provide guidance for recovering the status/path of a previous read-only download after a tool runtime interruption, so agents can avoid both unsafe duplicate exports and permanent UNKNOWN deadlocks.
5. Please link an applicable fixed release or supported workaround if one exists. Acknowledgment or triage alone should not be described as a verified fix.

Privacy

This public report intentionally excludes task/turn/call UUIDs, business/project names, source-table URLs and contents, contacts, local usernames/paths, tokens, cookies, full chats, screenshots and raw log files. Original bounded evidence is retained locally and has not been uploaded through this issue. No private in-app feedback session has been submitted by this report.

Acceptance on our side requires real original-task page access, source-bound complete spreadsheet download, successful report generation, and a later fresh-run check—not merely passing local tests.

Additional local evidence: durable connection and transport path (2026-10-13)

After reviewing related reports, we checked our own bounded logs, rather than adopting another reporter's root cause.

At 2026-10-13 09:49:10.335Z (within the same minute as the representative IAB inventory calls above), the desktop's AppServerConnection recorded:

hostId=durable transport=websocket closeCode=1006
message="WebSocket was closed before the connection was established"
initialized=false wasInitialized=false cause=transport_closed next=error

This is correlation, not proof that the durable connection failure causes the IAB discrepancy.

A later bounded, unauthenticated HTTPS transport probe to the root of codex-cloud-backend.chatgpt.com compared direct access with the machine's already-configured loopback HTTP proxy:

• Direct: curl connection timeout after approximately 6.02 seconds; HTTP 000; no TLS handshake completed.
• Existing proxy: TLS handshake completed in approximately 0.65 seconds; HTTP 403 received in approximately 1.14 seconds.
• No credentials, cookies or bearer tokens were sent; no proxy or system setting was changed.
• HTTP 403 here confirms a response on that transport path, not successful authentication or a working WebSocket/browser session.
• This was a separate command-process probe. It does not establish the actual proxy inheritance or network path of the browser child process or desktop durable transport.

The generated unified-computer-use manifest contains no explicit HTTP_PROXY/HTTPS_PROXY/ALL_PROXY entries. That absence alone does not prove the running process lacks inherited proxy settings. We have not patched the generated manifest or bundled launcher.

Could the team confirm a supported persistent proxy configuration for the managed CUA/durable connections and whether this observed connectivity split can produce the inventory/no-route behavior? Reports of TUN or launcher-patch workarounds from other users are not being treated as official fixes or copied into this installation.