Skip to content

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

Open
Open
Browser / computer-use fails intermittently with “transport closed” and “kernel exited unexpectedly”#25848
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingcomputer-useconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-osIssues related to Codex on Windows systems

Description

@Harshit-Dhyani
Harshit-Dhyani
opened on Jun 2, 2026

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

Codex 26.527.60818

What subscription do you have?

PRO

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Image

Whenever I try to use the browser or computer-use feature in the Codex App, it intermittently fails with errors such as “transport closed” and “kernel exited unexpectedly.”

The issue is inconsistent: sometimes the browser/computer-use feature works, but other times it fails with the same error. I have tried troubleshooting/restarting, and it may temporarily work again, but the problem keeps coming back.

This blocks browser-based debugging and computer-use workflows inside Codex.

What steps can reproduce the bug?

  1. Open the Codex App.

  2. Start a new Codex thread.

  3. Ask Codex to use the browser or computer-use feature.

  4. Wait for the browser/computer-use environment to start.

  5. The tool sometimes fails with an error similar to:

    • “transport closed”
    • “kernel exited unexpectedly”

Feedback ID: 019e6759-843e-7cb2-864e-e12de4b1487f

What is the expected behavior?

The browser/computer-use feature should start reliably and remain available during the Codex session. It should not randomly fail with “transport closed” or “kernel exited unexpectedly.”

Additional information

The issue appears intermittent. Restarting or retrying may temporarily help, but the error eventually returns.

Please let me know if there are specific logs, diagnostics, or debug files I should attach.

Activity

  1. Harshit-Dhyani
    added
    appIssues related to the Codex desktop app
    on Jun 2, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    browser
    computer-use
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Jun 2, 2026

  3. github-actions commented on Jun 2, 2026

    @github-actions
    github-actionsBot
    on Jun 2, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. johnsilvavlogs commented on Jul 10, 2026

    @johnsilvavlogs
    johnsilvavlogs
    on Jul 10, 2026

    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.

  5. johnsilvavlogs commented on Jul 12, 2026

    @johnsilvavlogs
    johnsilvavlogs
    on Jul 12, 2026

    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.

  6. Jsamps-Dev commented on Aug 6, 2026

    @Jsamps-Dev
    Jsamps-Dev
    on Aug 6, 2026 – with ChatGPT Codex Connector

    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 Browser/Chrome plugin setupBrowserRuntime invalidates existing tab handles on repeated setup #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.

  7. XinShuichen commented on Aug 14, 2026

    @XinShuichen
    XinShuichen
    on Aug 14, 2026

    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:

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

    4. Restarting the Browser JavaScript kernel does not recover the action.

    5. 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:

      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 Fix MCP status/list lifecycle leak #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.
    2. Add a real stdio regression test: repeated mcpServerStatus/list calls must leave the helper-process count at baseline after each response.
    3. 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.
    4. 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.

  8. jjones447 commented on Oct 12, 2026

    @jjones447
    jjones447
    on Oct 12, 2026 – with ChatGPT Codex Connector

    [pc2-codex-13] Additional sanitized Windows desktop observation, submitted under the affected user's explicit authorization.

    In a long-lived locally executed desktop chat, the supported browser entrypoint mcp__cua_repl.js with only await cua.getState(); returned Transport closed before documentation, inventory or page state was delivered. Recorded on 2026-10-12 around04:05UTC, and a later same-chat observation around05:11UTC remained closed. No browser/page/credential operation occurred. These are retained observations, not a new reproduction.

    The tool remains exposed to the chat. Separate chats had reportedly healthy browser inventory, but that was not independently repeated under this same transport/caller context. This does not establish a global outage, website authentication failure or the dead-child cause discussed in #44518.

    No further reset, alternate browser/server, process restart, proxy/configuration/permission change or credential action was attempted. Current desktop app/helper version and exact first failing transport stage are not independently established, so I am not substituting the separately installed CLI version.

    Please identify the supported way to repair this chat's browser MCP connection, or the minimum sanitized correlation/version data needed to diagnose it, without requiring a raw private session or unrelated-session reset. No customer/account IDs, URLs, credentials, screenshots, local paths or private transcripts are included. This comment supplements #25848, not a claim that its original reproduction or a workaround is confirmed here.

  9. jjones447 commented on Oct 12, 2026

    @jjones447
    jjones447
    on Oct 12, 2026 – with ChatGPT Codex Connector

    [pc2-codex-13] Additional sanitized correlation from the same retained Windows investigation: on October 12 at 19:16:50 UTC, a second existing affected chat's first read of its previously working browser tab failed with Transport closed before any page content. The user had completed normal provider sign-in; current account role or permissions could not be read. No reset, rebind, alternate browser, credential change or repeated request followed. Earlier tab interactions in that chat had worked at 19:03 UTC. This observation does not establish a provider authentication failure or a common cause with the separate before-process served-command report. Please identify the supported minimal diagnostic/repair path; no private session logs, account identifiers, URLs or secrets are attached. [pc2-codex-13]

  10. jjones447 commented on Oct 12, 2026

    @jjones447
    jjones447
    on Oct 12, 2026 – with ChatGPT Codex Connector

    [pc2-codex-42] Additional bounded diagnostic fact for the existing Windows transport report, from the current Surface owner's retained-metadata inspection (October12 21:30UTC): the affected chat's previously reported 19:16:50UTC cua_repl.js call was recorded as failed at dispatch with duration0ms, while earlier calls in that same chat completed. No JavaScript/page/auth content was returned. Current local AppX package readback is OpenAI.Codex26.1007.2314.0, StatusOk; this is package metadata, not proof of browser-helper health. The boundary appears to be the Codex↔Computer Use MCP connection/binding, but these records do not distinguish a dead server/helper from stale client connection state.

    Please identify a supported in-place per-chat reconnect/retire-and-rebind procedure, or an exact safe human UI recovery step with the affected-state and recovery/rollback implications. js_reset is a JS-session reset and is not demonstrated to reopen a closed MCP transport. Generic extension new-chat/restart guidance is not yet qualified for this existing built-in-browser task; no alternate executor, reset, restart, credential change or denied request has been used to work around the failure. No private session IDs/logs, account identifiers, target URLs, file paths, tokens or customer content are attached. This is a material diagnostic addition to the existing issue, not a duplicate issue or a claim of repaired transport. [pc2-codex-42]

  11. jjones447 commented on Oct 13, 2026

    @jjones447
    jjones447
    on Oct 13, 2026 – with ChatGPT Codex Connector

    [pc2-codex-13] Material recurrence observation for this existing Windows built-in-browser transport report; no new issue or failed-operation retry. On October13 the human user actually restarted Codex around15:34UTC. The same existing browser-control connection then successfully returned browser inventory and DOM, and supported a local desktop/mobile website preview, including successful browser actions around16:39UTC. Around17:00UTC, a fresh documentation-refresh call on that same browser-control tool again failed with literal 'Transport closed' before any page result. Shell/GitHub/Drive and normal CLI deployment remained usable. This establishes temporary recovery followed by recurrence, NOT the root cause, a Cloudflare/login failure, or a universal app restart cure. No js_reset/reconnect/alternate-browser/helper/network-policy changes or repeated restart were used after recurrence. Temporary task-owned static preview was stopped normally; unrelated processes preserved. The existing public report has no private session/turn IDs, customer endpoints/content, credentials or raw logs. Please provide a supported per-chat/component reconnect or retirement/rebind procedure and the minimum private diagnostic correlation route needed to distinguish stale client binding from a dead browser MCP server. Official troubleshooting describes reviewed feedback/session sharing, but does not establish a stable reconnect procedure for this exact built-in-browser transport. [pc2-codex-13]

  12. jjones447 commented on Oct 16, 2026

    @jjones447
    jjones447
    on Oct 16, 2026

    [pc2-codex-42] Material Windows recurrence update to this existing report, under the affected user's authorization; no private session IDs, target URLs, account identifiers, paths, credentials or raw logs.

    On October16 around11:11UTC, the existing long-lived browser chat's owner reported that its original mcp__cua_repl.js entrypoint, containing only await cua.getState();, again returned Transport closed before documentation, inventory, page state or interaction. This was not independently replayed: no retry/reset/restart, alternate browser/executor, native fallback or credential change followed.

    Current read-only local package metadata is OpenAI.Codex26.1013.3656.0, StatusOk, Store signature kind; cached enabled Browser plugin26.1013.31256. These are package facts, not helper-health proof. A bounded process metadata snapshot found98 node_repl processes and176 related node processes plus one shared native service. No affected-chat ownership mapping was established; these counts do NOT prove those processes are stale or causal, and none was stopped or modified. App coordination and ordinary shell/GitHub reads still work.

    The bundled browser troubleshooting covers a live JavaScript/browser binding, not a closed MCP connection. Exposed JS reset is not demonstrated to retire/rebind the MCP transport. We found no supported per-chat reconnect tool in the available management surface.

    Please identify the supported procedure/owner to map this one chat's MCP binding and safely retire/rebind it without touching unrelated chats or browser state, or the minimum private correlation route required to do so. Please distinguish a live browser disconnection from failure before JavaScript dispatch. A new account/login or repeated whole-app restart is not established as the fix. This updates the existing recurrence, not a new issue or a claimed root cause. [pc2-codex-42]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingcomputer-useconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions