Windows: browser runtime fails before bootstrap with failed to write kernel assets (os error 3) #41359

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   browser

   on Aug 28, 2026
2. aidawilliam41-ops commented on Sep 8, 2026

   

   aidawilliam41-ops

   on Sep 8, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows observation: missing per-server temp directories; kernel reset did not recover them

   A related occurrence on 2026-09-08, Codex Desktop 26.901.6511.0, provides a narrower filesystem observation and a successful scoped recovery.

   Both the unified CUA getState entry point and a minimal native node_repl JavaScript call failed before executing JavaScript with:

   failed to write kernel assets: The system cannot find the path specified. (os error 3)
   

   Kernel-reset operations returned successfully, but subsequent initialization still failed.

   Bounded read-only inspection identified the two task-owned runtime servers and their cached per-server temporary-directory paths. Both directories were absent. No memory dump, raw process contents or unrelated paths are attached.

   After explicit owner authorization, only those two missing empty directories were recreated within the verified temporary-root scope. No server/process restart, executable replacement, configuration or permission change was made. Afterwards:

   • Unified CUA initialized and accessed the intended existing browser tab.
   • Native node_repl executed a minimal JavaScript check successfully.

   This establishes missing cached temporary directories as the immediate failure condition in this occurrence. It does not establish who removed them, why they disappeared, or that every occurrence in this issue has the same cause.

   Please make initialization/reset validate the cached temporary directory and safely recreate or replace a missing runtime-owned directory, with ownership/path checks. If recovery is not possible, return the failing filesystem operation and a sanitized destination type/path. A successful reset response should not leave initialization permanently dependent on an absent directory.

   No browser content, credentials, local usernames, task IDs or raw logs are included. This adds evidence to the existing error-signature issue rather than asserting a new independent root cause.
3. augustusf7m-dev commented on Sep 13, 2026

   

   augustusf7m-dev

   on Sep 13, 2026 – with ChatGPT Codex Connector

   More actions

   Reproduced on Windows Codex desktop on 2026-09-13. Both browser control (cua_repl initial getState) and the separate node_repl initialization fail immediately with failed to write kernel assets: The system cannot find the path specified. (os error 3). The error occurs before browser/tab discovery or any site authentication. Resetting both JS kernels and fully closing/reopening Codex did not resolve it. Chrome itself remains open and signed in, but Codex cannot inspect its tabs. This blocks a read-only mailbox verification workflow. App version and calculated failing asset path were not exposed to this session. No account identifiers or private content included.
4. aidawilliam41-ops commented on Sep 17, 2026

   

   aidawilliam41-ops

   on Sep 17, 2026 – with ChatGPT Codex Connector

   More actions

   A September 17, 2026 Windows occurrence adds file-I/O trace evidence to the missing-directory recovery already reported here.

   At 07:59:55.261 UTC, ETW identified node_repl.exe attempting to write package.json inside a missing %TEMP%\.tmp<id> directory. The Temp parent existed. Initialization failed with failed to write kernel assets: The system cannot find the path specified. (os error 3). js_reset returned successfully, but initialization still failed.

   Creating only that missing empty directory restored operation: a kernel-start check, import @oai/sky, and sky.list_windows succeeded.

   The exact directory also appears in Kerish Doctor's Backup/EmptyFolders.bck, last modified at 06:54:05 UTC. This is a cleanup correlation, not proof of the deleting actor or time; no per-entry timestamp was established.

   Expected: initialization/reset should validate its retained runtime-owned directory and safely recreate or replace it when absent, or expose the failing operation and sanitized destination.

   No private paths, captured content, or raw traces are included.
5. Tastal commented on Sep 21, 2026

   

   Tastal

   on Sep 21, 2026

   More actions

   Reproduced again on Windows with OpenAI.Codex 26.915.4065.0 on September 21, 2026.

   Environment verified locally:

   • Installed Windows package: OpenAI.Codex 26.915.4065.0.
   • OS version reported by .NET: Microsoft Windows NT 10.0.26200.0.
   • Unified browser-control tool: cua_repl.
   • The in-app browser tab remains visible and displays its existing loaded page.

   Earlier in the same task, browser automation successfully read rendered page content. Later, even the smallest entry point failed before returning any browser/tab state:

   await cua.getState();

   Exact tool error (Windows Chinese locale):

   failed to write kernel assets: 系统找不到指定的路径。 (os error 3)
   

   The Chinese text means "The system cannot find the path specified."

   A request to acquire the existing tab through cua.getTab(...) fails with the same error. The tool's js_reset returns js kernel reset, but a fresh getState() still immediately fails. This initialization/reset sequence was reproduced multiple times. The observed calls returned in roughly 0.04 seconds, before any page operation.

   Checks performed:

   • The shell's TEMP and TMP parent directories exist.
   • The user-level .codex/node_repl directory exists.
   • The visible in-app browser page continues to display while agent-side automation is unavailable.
   • A bounded application-log search did not reveal the failing asset destination or a stack trace.
   • Reset success did not restore initialization.
   • No directory was speculatively created, and no browser profile, permissions, or runtime configuration was changed.
   • A full app restart has not been confirmed as a completed recovery test in this occurrence.

   This adds a newer-version reproduction of the existing error signature. The earlier comments about missing retained per-server temporary directories are a relevant hypothesis, but the exact failing child directory and any cleanup actor have not been established on this machine.

   Expected:

   1. Browser-control initialization should recover safely if its own retained temporary directory is missing.
   2. If it cannot recover, return the failing filesystem operation and a sanitized destination so the issue can be diagnosed without guessing.
   3. A successful reset should leave the runtime able to reinitialize, or clearly report the remaining initialization failure.

   Impact: agent-driven browser work is blocked even though the user can still see the in-app browser. No webpage content, environment URLs, account identifiers, screenshots, full session transcript, or raw logs are included in this report.
6. qihangzhang-272 commented on Sep 30, 2026

   

   qihangzhang-272

   on Sep 30, 2026

   More actions

   Causal reproduction (not correlation) on Windows 26.928.2636.0 — plus the recovery test that was still open

   Environment:

   • Windows 10 x64
   • Codex Desktop package OpenAI.Codex 26.928.2636.0
   • Runtime runtimes\cua_node\be2aaea167c12e53\bin\node_repl.exe, 34,047,944 bytes, SHA-256 714280c405fbd5b60b9e1eac8d96dcfd0d4bbacc894ab44c45de3d3a2cf58539
   • All Codex processes run as the same interactive user; no sandbox-user divergence is involved

   This adds a controlled causal reproduction, the control cases that rule out the runtime deleting its own directory, and the recovery test that @Tastal's report left unconfirmed.

   1. Reproduction, deterministic (3/3 runs)

   1. Launch node_repl.exe with an MCP client and complete initialize.
   2. Call js once -> all 10 kernel assets appear in %TEMP%\.tmp<id>; the call works.
   3. Delete that one directory by hand.
   4. Call js_reset -> returns js kernel reset, success.
   5. Call js -> failed to write kernel assets: The system cannot find the path specified. (os error 3), isError: true.

   The 10 assets are: diagnostics.js, kernel.js, meriyah.umd.min.js, package.json, privileged-node-repl-config.js, privileged-node-repl.js, realmChecks.js, tracing.js, trusted-worker.js, worker-runtime.js.

   2. Control cases

   Variation	Result
   delete the directory, then call js without js_reset	still works — an already-started kernel is unaffected
   js_reset alone, directory intact	does not delete the directory
   kernel timeout (js execution timed out; kernel reset)	does not delete the directory
   brand-new instance	recovers immediately

   So a kernel reset that is not preceded by a missing directory cannot itself produce this error, and a missing directory is sufficient to produce it, permanently, for that process. The retained path is computed once at startup and is never recreated.

   3. Directory lifecycle — why empty .tmp* directories are not evidence of a failed write

   Event	Directory state
   process start	created, 0 files (ACL hardened: CodexSandboxUsers modify + a capability SID)
   first js call	10 assets written; one node.exe kernel child spawned
   graceful exit (stdin EOF, exit 0)	directory deleted
   hard kill	directory left behind, empty

   On the affected machine, 22 of 24 live node_repl.exe processes no longer had the directory created at their start time; only the two newest did. That is the state that produces this error on the next kernel start.

   This also rules out a permissions cause: the directories carry an ACE for CodexSandboxUsers plus a capability SID, and the owning user has FullControl, on both the working and the failing directories.

   4. Recovery — the open question in @Tastal's comment

   A full app restart was not required here. node_repl is instantiated per thread, so a new thread receives a fresh instance and a fresh directory. Verified end to end:

   • new instance started at 12:00:07 local (parent codex.exe), working set 16.7 MB
   • %TEMP%\.tmpr7W6L4 created at 12:00:07, containing all 10 assets
   • kernel child node.exe --eval ... kernel.js spawned at 12:00:37
   • const { sky } = await import("@oai/sky"); await sky.list_apps() returned 40 apps, with window ids, titles and isRunning

   So js_reset cannot recover this state, but a fresh instance can — which is consistent with a retained path that is only computed once.

   5. Where the directories went, and what did not remove them

   The disappearance window on this machine is bounded to a 28-minute span (10:54:42 to 11:22:51 local), and that span contains exactly one deliberate manual cleanup that removed 131 stale %TEMP%\.tmp* directories while troubleshooting. This is consistent with @aidawilliam41-ops's cleanup-tool correlation.

   Negative result: a continuous filesystem watch on %TEMP% for 15 minutes (create / delete / rename on .tmp*) recorded no deletion events at all. Whatever removes these directories is not a constantly running actor, and they do not disappear on their own.

   6. Requested fix

   1. On initialization and on js_reset, validate the retained runtime-owned temp directory and safely recreate it when absent, with ownership and path checks before creating.
   2. A successful js_reset should leave the runtime able to reinitialize, or clearly report the remaining initialization failure — currently it reports success.
   3. If recovery is not possible, return the failing filesystem operation and a sanitized destination, instead of only os error 3.
   4. For diagnosability: a hard-killed instance leaves an empty directory behind, which is indistinguishable from a failed unpack unless the lifecycle above is known. Exposing the computed destination would remove that ambiguity.

   No browser content, credentials, local usernames, machine names, thread ids or raw logs are included.
7. Klggz7 commented on Oct 4, 2026

   

   Klggz7

   on Oct 4, 2026

   More actions

   Additional reproduction on Windows, 2026-10-04:

   • Codex Desktop AppX: 26.917.9434.0
   • Product and bundled plugins: 26.917.71314
   • @oai/sky: 0.7.1
   • Platform: Microsoft Windows NT 10.0.28120.0 x64

   A read-only review of 104 Codex session files from 2026-09-10 through 2026-10-04 found:

   • 14 sessions with structured CUA calls, totaling 638 calls.
   • 10 exact failed to write kernel assets ... (os error 3) results across 3 distinct long-lived tasks.
   • The first failure occurred when those tasks were approximately 7.4, 9.1, and 9.2 days old.
   • The first failing turns were 53, 8, and 43 respectively, so task age appears more consistent than turn count.
   • One later failure occurred when a task was approximately 19.3 days old.
   • After the first kernel-assets failure, none of the three tasks showed a confirmed same-task CUA recovery.
   • Four js_reset attempts returned success, but the next initialization call failed identically.

   Same-machine controlled comparison:

   • The affected task failed @oai/sky initialization twice, including after js_reset.
   • At the same time, a fresh agent/task successfully initialized @oai/sky; sky.list_apps() returned 40 apps and 5 windows.
   • The native helper and named pipe were live, and the plugin manifests and runtime paths were present.

   This further supports a per-thread retained temporary/kernel-assets path failure rather than global installation or cache corruption.

   Browser acknowledgement observation:

   • 10 createBrowserTab timeouts were found.
   • 8 were followed by successful browser-state reads.
   • In at least one case, the timed-out call had actually created the requested target tab.

   It would be useful for create/navigation acknowledgements to distinguish an unknown outcome from a confirmed action failure, so agents do not repeat an action that may already have completed.

   No session transcript, browser content, account identifiers, local usernames, machine names, raw logs, or private paths are included.
8. herreigna-lab commented on Oct 4, 2026

   

   herreigna-lab

   on Oct 4, 2026

   More actions

   Additional reproduction on Windows, 2026-10-04: the same kernel-assets failure also blocks the bundled native Windows Computer Use skill, not just browser bootstrap.

   Environment:

   • Windows 11 Pro, x64, build 26200.
   • Bundled CLI reports codex-cli 0.160.0 (CLI version, not the desktop app version).
   • Bundled Computer Use skill version: 26.930.31730.

   Minimal attempted initialization through the supplied mcp__node_repl__js tool:

   if (!globalThis.sky) {
     const { sky } = await import('@oai/sky');
     globalThis.sky = sky;
   }

   Actual tool output:

   failed to write kernel assets: El sistema no puede encontrar la ruta especificada. (os error 3)
   

   The JS session reset tool returned js kernel reset; retrying the same initialization then produced exactly the same error. No app/window enumeration or UI input was reached. Ordinary shell diagnostics remained available.

   Impact: the assistant could not manipulate the already-open Intel Graphics Command Center. Manual adjustment by the user did produce a visible display change, so the inaccessible UI controls themselves were functional.

   Separate assistant reliability issue encountered in the same workflow: earlier driver-based attempts had been directed at the internal notebook display instead of the requested external HDMI TV, and changes were presented as applied without verifying a visible result. A subsequent read-only QueryDisplayConfig check identified that mismatch. This is not claimed to be the cause of the kernel-assets error, but it worsened the impact of the automation failure.

   Please expose a sanitized failing destination/operation for the kernel-assets error and provide a supported repair. The assistant should also avoid claiming successful UI changes when bootstrap failed or only an unverified driver return value is available. No private logs, screenshots, or session transcript are attached.
9. qihangzhang-272 commented on Oct 7, 2026

   

   qihangzhang-272

   on Oct 7, 2026

   More actions

   Follow-up on 26.930.7945.0 — still reproduces, with evidence that rules out an external cleanup tool

   Environment:

   • Codex Desktop OpenAI.Codex 26.930.7945.0 (installed 2026-10-06 04:59 local)
   • Runtime runtimes\cua_node\71e3f41277f96d73\bin\node_repl.exe
   • Windows 10 x64

   This continues my earlier report in this issue. The signature is unchanged and still reproduces on this build.

   1. A fresh instance works, so the machine and the runtime binaries are fine.

   Launching node_repl.exe from the current runtime and issuing one js call:

   js call completed in 181 ms -> "probe-ok"
   new directory .tmp<id> contains 10 entries:
     diagnostics.js  kernel.js  meriyah.umd.min.js  package.json
     privileged-node-repl-config.js  privileged-node-repl.js
     realmChecks.js  tracing.js  trusted-worker.js  worker-runtime.js
   

   2. 12 of 14 live node_repl processes no longer have the directory created at their start time.

   Each instance creates %TEMP%\.tmp<id> at startup. Matching live processes to directories by creation time (within 6 seconds): only 2 of 14 matched, and those two were the newest — started minutes earlier, directory still empty because no js call had run yet. The other 12 have no directory at all, so any kernel start in those processes fails with os error 3.

   3. The survival pattern of existing directories argues against an external cleaner.

   Grouping the %TEMP%\.tmp* directories by creation date:

   created	still present
   09-30 .. 10-05	42
   10-06	0
   10-07	50

   A generic cleanup pass (Storage Sense, Disk Cleanup, an antivirus cleanup job, a manual sweep of %TEMP%) removes the oldest entries first. Here the oldest directories survive while every directory created on one particular day is gone. I also checked the scheduled cleanup tasks: SilentCleanup last ran 10-06 23:36 and StorageSense 10-06 12:22, and neither matches this distribution.

   The distribution is instead consistent with "the directory is removed as part of something that happens to a live instance", which the next point describes.

   4. The teardown that removes the directory is not the same event as process exit.

   Re-verified on this build: closing the MCP client's stdin (graceful teardown) ends the process in 219 ms and the directory disappears with it. Separately, 14 node_repl processes are alive on this machine right now, 12 of them with no directory.

   So a retained directory can be gone while its process is still running and still reachable by the client. That is the state this issue reports: the client keeps calling a process whose directory was already removed, and the runtime — which computes that path once at startup — never recreates it.

   5. Practical impact, unchanged

   • js_reset returns success but does not recover.
   • A newly created instance works immediately.
   • The error gives no indication which of these states the process is in.

   Requested

   1. On initialization and on reset, validate the retained directory and recreate it when absent, with the same ownership checks used at creation.
   2. Do not remove the retained directory on a teardown path that leaves the process alive. If the process keeps serving, its working directory has to survive.
   3. If recovery is not possible, return the failing filesystem operation and a sanitized destination, rather than only os error 3.

   No browser content, credentials, local usernames, machine names, thread ids or raw logs are included.
10. Rajann7 commented on Oct 8, 2026

    

    Rajann7

    on Oct 8, 2026 – with ChatGPT Codex Connector

    More actions

    On Windows, the Browser runtime fails with failed to write kernel assets … (os error 3). The issue persists after a runtime reset, reboot, and signing out and back in. Please provide a supported fix.
11. carabinshely commented on Oct 13, 2026

    

    carabinshely

    on Oct 13, 2026 – with ChatGPT Codex Connector

    More actions

    Additional Windows reproduction observed on October 12–13, 2026.

    Environment (read-only verification on October 13):

    • Installed Windows package: OpenAI.Codex 26.1007.2314.0 (package version, not independently read from the About dialog).
    • OS version reported by .NET: 10.0.26300.0.
    • Exposed unified browser tool: mcp__cua_repl.js.
    • Chrome and Edge processes remain running; ordinary shell and GitHub API operations work.

    Minimal observed calls:

    await cua.getState();

    and, in a later attempt starting explicitly with Edge:

    let browser = await cua.getBrowser({ id: "edge" });

    Both fail before returning browser inventory or binding a tab:

    failed to write kernel assets: The system cannot find the path specified. (os error 3)
    

    Observed return times were approximately 0.05–0.09 seconds, despite a 60-second tool execution timeout. No website operation or authentication screen is reached.

    Reset sequence actually tested on October 12:

    1. cua.getState() fails with the error above.
    2. mcp__cua_repl.js_reset returns js kernel reset.
    3. A fresh cua.getState() fails identically.
    4. October 13's explicit Edge entry point still fails identically.

    Earlier browser operations in this long-lived task succeeded. The owner suspects session-local retained state and is moving the outstanding work to a new task. We have not yet tested a fresh-task A/B comparison, identified the missing directory, or established a cleanup actor. The earlier missing retained-directory evidence in this issue is relevant, but we are not claiming that root cause was proved in this occurrence.

    Impact: final read-only browser verification is blocked while the browsers themselves remain running. Repeated retries were stopped. No browser restart, process killing, profile reset, guessed directory creation or security/trust override was performed.

    A separate earlier setupAtlasRuntime attempt returned privileged native pipe bridge is not available; browser-client is not trusted; that is being reported separately in #21781 and is not asserted to have the same cause.

    Expected: initialization/reset should safely recover its owned missing assets directory, or return a sanitized failing destination and filesystem operation. A reset success should not mask a persistent initialization failure.

    This comment includes only sanitized tool output and environment metadata: no browser contents, credentials, local user paths, machine identifiers, private task IDs, visitor data or raw conversation/log dump.
12. 5-Brothers-Studio commented on Oct 16, 2026

    

    5-Brothers-Studio

    on Oct 16, 2026 – with ChatGPT Codex Connector

    More actions

    Additional Windows occurrence on October 16, 2026, during 01:22:11–01:22:23 UTC (exact failure second not captured).

    Environment: Windows 10, build 10.0.19045, AMD64. The separately installed CLI reports codex-cli 0.162.0-alpha.17.2; this is not a verified desktop-app version or a CLI reproduction. Desktop-app version remains unknown.

    The documented initial call to the exposed supported browser tool was:

    await cua.getState();

    It failed before JavaScript evaluation, page inventory or browser authentication:

    failed to write kernel assets: The system cannot find the path specified. (os error 3)
    

    A scoped current-thread startup-log check found its last genuine CUA STARTING/READY bracket at October 15 20:02:18.797–20:02:18.929 UTC. Later READY-only notifications, including October 16 01:06:23.712 UTC, did not establish a replacement process or successful tool access.

    An owner-provided inspect-only recovery helper had previously stopped because it could not identify one unambiguous retained TempDir reference. No repair was applied. This occurrence's missing destination and directory lifecycle remain unproved; the earlier missing-directory evidence here is relevant but does not establish our root cause. No recovery identity/uniqueness guards were relaxed.

    No process was selected or killed, runtime directory created/deleted, global TMP/TEMP changed, session cleared, or credential/security setting changed during this check. No new reset/restart test is claimed. Ordinary shell execution, public web reading and a separate email connector remain available while browser-dependent work is blocked.

    Please expose the sanitized failing filesystem operation and owned destination, and provide a supported recovery that preserves existing sessions. This adds a current occurrence to the existing signature report rather than filing a duplicate issue.

    No project/app names, accounts, tester data, codes, private paths, process IDs, screenshots, raw logs or session transcript are included.