Browser / computer-use fails intermittently with “transport closed” and “kernel exited unexpectedly”

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

• #25827
• #25226
• #25511
• #25488
• #25357

Powered by Codex Action

Additional macOS reproduction and recovery evidence from Codex Desktop:

• Codex Desktop: 26.707.31428 (build 5059)
• macOS: 26.5.2 (25F84)
• Computer Use plugin: 1.0.1000366
• Observed error: the loaded mcp__node_repl__js / Computer Use handle returned a hard Transport closed.
• The underlying SkyComputerUseService was still alive, so this was not a complete service failure.
• A process snapshot showed substantial adjacent helper fan-out: 18 SkyComputerUseClient event-stream mcp processes and 18 cua_node/bin/node_repl processes, plus one service.

Recovery that worked without restarting Codex or WhatsApp:

1. Call mcp__node_repl__js_reset.
2. Reinitialize the plugin-owned runtime with setupComputerUseRuntime({ globals: globalThis }).
3. Run a read-only Finder get_app_state smoke test.
4. Run a read-only WhatsApp get_app_state smoke test.

Both Finder and WhatsApp returned their accessibility trees immediately after the reset. No helper processes, apps, or the main Computer Use service had to be killed or restarted.

This suggests at least one failure mode is an already-loaded MCP/kernel transport becoming wedged while the underlying Computer Use service remains healthy. A useful product-side recovery would be to detect Transport closed, discard/recreate the loaded node_repl transport automatically, and retry a read-only probe once. The large unreaped helper/client fan-out may be related and is worth checking as a recurrence contributor.

Current-build recurrence boundary and healthy Chrome control from macOS on 2026-07-12:

• Codex Desktop 26.707.51957 (build 5175)
• bundled CLI 0.144.0-alpha.4; global CLI 0.144.1
• macOS 26.5.2 (25F84)
• Chrome/Browser plugin caches both match the GUI build 26.707.51957
• Computer Use plugin cache 1.0.1000387

The machine currently has dozens of paired SkyComputerUseClient event-stream mcp and cua_node/bin/node_repl helpers, with some pairs several hours old while new pairs continue to appear. Desktop logs from the same day also show repeated 30-second app-server initialize handshake timeouts across reconnect attempts (for example attempts 37, 44, 54, and 162). I am treating those handshake timeouts as adjacent lifecycle evidence, not as proof of a Chrome-extension root cause.

Most useful control: in a fresh task/runtime on the same installed build, the Chrome extension backend initialized successfully and browser.user.openTabs() returned three live Chrome tabs immediately. This rules out a globally broken Chrome extension/native-host installation for the current incident. It fits the failure pattern already described here: an older task-local Browser/Computer Use transport can wedge or close while a fresh runtime on the same machine and build remains healthy.

The product ask is automatic containment and recovery at the task boundary:

1. Detect a closed/wedged loaded node_repl transport.
2. Retire its task-owned helper/client pair.
3. Recreate the runtime and retry one read-only browser/Computer Use probe.
4. Bound and reap stale helper fan-out without requiring a full Codex restart.
5. Log a capability receipt that distinguishes Chrome extension/backend health, Computer Use service health, and task-local transport health.

That distinction would prevent misleading reinstall guidance when Chrome itself is connected and a fresh task can prove it.

Disclosure: This comment is being posted by the user's Codex assistant, with the user's explicit authorization and on their behalf. It is sanitized: no private URLs, page contents, account data, credentials, or raw logs are included.

Independent Windows reproduction on the current Store build

This is the same intermittent transport closed / kernel exited unexpectedly failure family, reproduced on a substantially newer build with a more precise failure boundary.

Environment

• ChatGPT/Codex Microsoft Store package: OpenAI.Codex 26.730.8199.0 (x64)
• Bundled Browser/Chrome plugin: 26.730.61639
• Platform: Windows x64
• Package state: Status: Ok; Store signature valid
• The package was installed on 2026-08-05 and the app was fully restarted on 2026-08-06 before the reproduction.

Deterministic failure boundary

A durable stage log from one affected task showed:

1. browser-client.mjs import succeeded.
2. setupBrowserRuntime() succeeded.
3. agent.browsers.get("chrome") succeeded.
4. Session naming succeeded.
5. chrome.user.openTabs() succeeded and returned 17 tabs.
6. The exact intended BrowserUserTabInfo object was selected.
7. The per-task Node-backed kernel exited during chrome.user.claimTab(tabObject) before the promise returned.

The tool reported:

node_repl kernel exited unexpectedly
kernel_status: exited(code=1)
reason: stdout_eof

No recoverable JavaScript/browser API exception was returned.

A separate bounded retest in a fresh task produced the broader lifecycle symptoms:

• Initial browser setup could itself terminate the worker with stdout_eof.
• After exactly one reset, a self-contained read-only openTabs() probe succeeded and returned 15 tabs.
• On the next call, the previously created Chrome binding was unexpectedly undefined while the app remained alive, indicating cross-call session-affinity loss.
• A final self-contained agent-owned blank-tab transaction (no claimTab()) again terminated the worker with stdout_eof.

Ruled-out causes

The following were checked and did not resolve or explain the failure:

• Chrome/extension availability: the extension host was alive and open tabs were enumerated successfully.
• Stale extension host: it was restarted after exact PID/path validation; the failure persisted.
• Competing per-task browser worker: the other validated worker was released; the failure persisted.
• Session/thread identity mismatch: request metadata showed session_id === thread_id.
• Corrupt Store package: AppX status is healthy and the package signature is valid.
• Whole-app/native crash: the ChatGPT/Codex app remained responsive, and no corresponding Windows WER app crash was recorded.

Suggested runtime fix

1. Preserve per-thread/per-task Node kernel and browser-session affinity across tool calls.
2. Make setupBrowserRuntime() idempotent: reuse a healthy runtime after a cheap health check instead of disposing/recreating it (closely related to #27128).
3. Contain failures from claimTab(), tabs.new(), and setup/bridge operations as bounded promise rejections with actionable stage/error metadata; never terminate the Node worker.
4. Ensure a failed browser operation leaves the kernel usable for a simple nodeRepl.write("alive") probe.
5. Add cleanup so a terminated worker cannot leave stale browser routes or native-pipe ownership behind.

Regression tests

Please test this sequence on Windows:

1. Fresh setup → select Chrome → openTabs().
2. Use the browser binding again in a second tool call to verify session affinity.
3. Create/finalize one agent-owned blank tab without claiming a user tab.
4. Pass the exact object returned by openTabs() once to claimTab(), then finalize it as a handoff.
5. Inject a backend failure at each stage and verify that the call returns a structured error while the Node kernel remains alive.

Safe containment already implemented locally

Until a signed runtime fix is available, the local protocol now:

• avoids this affected Chrome runtime during ordinary work,
• never loops setupBrowserRuntime() or resets,
• stops immediately on the first confirmed stdout_eof,
• preserves user-owned tabs,
• and uses an allowed connector or alternative surface when possible.

Detailed stage logs, timestamps, process IDs, app-log excerpts, and the sanitized reproduction transcript can be provided privately if a maintainer requests them.

Reward / recognition question

Because this report adds a current-build reproduction, isolates the exact worker boundary, rules out several common causes, supplies a containment protocol, and proposes concrete regression tests, please let us know whether OpenAI has any bug-reward, researcher-recognition, or account-credit program applicable to non-security reliability defects, and whether this report may qualify.

Disclosure: This comment is being posted by the user's Codex assistant with the user's explicit authorization. It is sanitized: no private URLs, page contents, account data, credentials, IP addresses, usernames, or raw logs are included.

Current macOS reproduction: helper accumulation leads to Browser policy-read failure, then Transport closed

This appears to connect the Browser/Computer Use transport symptom in this issue with the temporary MCP lifecycle leak discussed in #35485 and #38171.

Environment

• ChatGPT/Codex Desktop: 26.810.41047 (build 6570)
• Bundled app-server: codex-cli 0.148.0-alpha.9
• Bundled Browser/Chrome plugins: 26.810.41047
• macOS: Darwin 25.5.0, arm64

Reproduction and failure boundary

1. Fully quit and restart the desktop app.
2. Browser Use works normally for a few minutes in both the in-app browser and Chrome.
3. A later Browser action fails before navigation with:

``text
Browser Use could not complete this action because a browser security check was unavailable.
Reason: The admin-enforced policy could not be verified.
``

1. Restarting the Browser JavaScript kernel does not recover the action.
2. After terminating only the stale task-owned node_repl helper to force a clean rebind, later calls in the same Codex thread return a hard:

``text
Transport closed
``

The next user turn still routes to that closed transport, so the app-server/desktop registry retains the dead binding rather than creating a healthy replacement.

This was reproduced across unrelated origins and both Browser surfaces. The Browser service, browser tabs, ordinary network access, device attestation, and UI-level config/read / configRequirements/read remained healthy. No managed Browser deny rule was present.

Process and timing evidence

• After about 59 minutes of app-server uptime, there were 28 live cua_node/bin/node_repl processes, all direct children of the single desktop app-server.
• Their creation times increased monotonically during normal task/tool activity.
• One desktop log entry recorded mcpServerStatus/list taking 301,100 ms.
• Browser Use worked immediately after app restart, then failed after the long MCP status request and helper accumulation. Restarting the whole app clears the current pool but the problem recurs.

Source-level analysis

The bundled browser-client.mjs policy check calls config.readRequirements() and config.readAll() in Promise.all. A catch-all converts any exception from either read into the single "unavailable" result, which is then surfaced as codex-network-policy-unavailable / “admin-enforced policy could not be verified.” An actual policy deny uses a different result (codex-network-policy). This explains why a local config-capability transport failure is presented as an enterprise policy problem.

Current public openai/codex main (86b1123ff6b5d089a146be4e603a324cf454223a) also still has the temporary status-manager lifecycle gap:

1. mcpServerStatus/list is detached with tokio::spawn.
2. collect_mcp_server_status_snapshot_with_detail eagerly creates a fresh McpConnectionSet, collects inventory, calls only cancel_token.cancel(), and returns without awaiting mcp_connection_manager.shutdown() (lines 463-473).
3. The existing McpConnectionSet::shutdown() is explicitly documented to terminate owned stdio server processes.
4. AsyncManagedClient::shutdown() performs both cancellation and the transport shutdown; cancellation alone is not the same cleanup path.

PR #20447 (“Fix MCP status/list lifecycle leak”) proposed the narrow matching fix: await the RPC work and explicitly call shutdown() on temporary MCP managers. It was closed by the stale bot without being merged, while current main still shows the same lifecycle pattern.

Suggested fix and regression coverage

1. Port the narrow intent of #20447 to current main:

• keep mcpServerStatus/list inside the tracked/serialized request future;
• always await McpConnectionSet::shutdown() before a temporary status snapshot returns, including cancellation/error paths.

1. Add a real stdio regression test: repeated mcpServerStatus/list calls must leave the helper-process count at baseline after each response.
2. When a task-owned node_repl transport reports Transport closed, invalidate the registry entry and recreate it once instead of routing later turns to the dead handle.
3. In Browser policy evaluation, log which config read failed and distinguish “policy explicitly denied” from “local policy-read transport unavailable.” The current wording sends users toward enterprise/network troubleshooting even when no deny policy exists.

The source gap alone may not explain every transport failure in this issue, but it directly matches the observed helper growth, the 301-second status call, restart-only temporary recovery, and the subsequent Browser config-capability failure on this current macOS build.