[Windows app] Resumed task omits cua_repl after restart while a new @Chrome task works #46782

What version of the Codex App are you using?

Windows MSIX package version: 26.915.4065.0 (read from installed-package metadata, not the About dialog).
Bundled browser/computer-use plugin release: 26.915.31945.

What subscription do you have?

Signed in with ChatGPT. Exact subscription tier was not collected for this report.

What platform is your computer?

Microsoft Windows NT 10.0.19045.0, x64.
Google Chrome 153.0.8010.48; official Chrome extension 1.26.901.11451.

What issue are you seeing?

An existing local task (Thread A) cannot access the bundled cua_repl tool after a desktop-app restart, while a newly created local @Chrome task (Thread B) in the same running desktop application can access it and successfully read/control the same signed-in local Chrome session.

This is more specific than a browser being closed or an extension failing to connect:

• Thread A exposes node_repl, codex_apps, and codex_app, but no callable cua_repl/js. Re-mentioning @Chrome and sharing a Chrome tab in A did not restore that tool.
• Thread B exposes all four services, including cua_repl. Its actual cua.getState() / cua.getTab() calls and subsequent browser UI operations succeed.
• Desktop logs correlate these differences with the individual thread IDs. The two tasks use the same local host and desktop-app process/session.

The native @oai/sky route in A can discover/activate Chrome, but attempting to read the Chrome window stops with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

That route was stopped as instructed. This report does not request bypassing URL verification. The missing bundled browser tool and the native URL-verification failure are separate observations; their relationship has not been established.

What steps can reproduce the bug?

Observed sequence on September 20, 2026; a deterministic minimal reproduction from a clean install is not yet established:

1. Have a long-running local task A. Logs from an earlier desktop-app process show cua_repl reaching ready for A.
2. Restart the desktop application and resume A.
3. Ask A to use Chrome, including an explicit @Chrome mention and a shared tab.
4. Observe that A lacks a callable cua_repl tool and its MCP startup events list only the other three services.
5. Create a fresh local task B with @Chrome, without changing/reinstalling Chrome or its extension between A and B.
6. B loads cua_repl and successfully operates Chrome, while A still lacks it.

Sanitized diagnostic evidence

All times below are UTC on 2026-09-20. Thread identifiers are replaced with A/B. These are summaries of matching log events, not complete raw log lines.

Earlier ready events establish that A had loaded the service, not that its earlier browser operations succeeded. B's successful operations are independently visible in its tool results.

Additional read-only checks:

• Official Chrome extension is installed and enabled.
• Native messaging host registration, extension origin, and executable target agree; native host has a valid OpenAI signature.
• No related blocking policy was found in the ordinary user/machine Chrome policy locations checked. This is not an exhaustive security-software audit.
• Browser, Chrome, Computer Use, and unified Computer Use plugins are enabled globally.
• A global node_repl entry with browser/sky trusted services is present and is available to both tasks. Its causal relevance is unknown; this is not a pristine default configuration.
• Runtime-path resolution events for A and B select the same currently installed Codex and CUA runtime executables. Different historical session-creation version metadata is not evidence that A is currently running an older binary.
• No project-level configuration override was found in the checked task directories.

What is the expected behavior?

Resuming an existing task and explicitly invoking an enabled Chrome plugin should make its supported browser tools available, as in a new task. If a task's capability binding cannot be refreshed, the app should show an actionable explanation and a supported recovery path that preserves task history.

Please investigate why cua_repl is omitted for one resumed task but loaded for a new task in the same app session, and advise how to refresh/recover an affected task. The underlying cause (task binding, lifecycle, configuration, or another component) is not confirmed.

Related reports

• macOS: cua_repl does not respawn after launch.mjs/node_repl exit; createBrowserTab returns Transport closed in ~1ms #44518: session-specific cua_repl lifecycle failure on macOS; this report concerns an absent tool/startup event on Windows, not a callable tool returning Transport closed.
• Codex on Windows: Native Computer Use stops because it cannot determine Chrome’s current URL #43880: Chrome native URL-verification failure on Windows, matching the fallback error class here.
• Windows Computer Use intermittently unavailable despite native pipe and cua_repl being ready #45221: native Windows control unavailable despite cua_repl being ready; here the affected task lacks cua_repl entirely while another task's Chrome control works.

This public report excludes private URLs/page content, account identifiers, task IDs, usernames, absolute local paths, pipe addresses, screenshots, and complete raw logs.