Windows Desktop: elevated sandbox blocks node_repl; unelevated fixes bridge but Computer Use pipe missing

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

• #26862
• #26530
• #26110
• #26587
• #26528

Powered by Codex Action

Follow-up after reviewing the potential duplicates posted by the bot:

This issue appears to overlap with two related bug clusters, but I do not think it is a pure duplicate yet because it captures the transition between them on the same machine/session.

Related sandbox / node_repl reports:

• #26862 confirms the same windows.sandbox = "elevated" failure and the unelevated workaround.
• #26530 is a close match for the original os error 740 path and includes the useful observation that the npm Codex CLI 0.137.0 sandbox helper appears to contain an asInvoker manifest while the Desktop cached/bundled helper may not.
• #26110 is an earlier clean report that Browser and Computer Use both fail because node_repl hits Windows sandbox setup os error 740.

Related Computer Use native-pipe reports:

• #26587 closely matches the remaining failure after the bridge recovers: Browser/Chrome runtime can work, but Computer Use is unavailable because native pipe metadata/path is missing.
• #26528 is related but slightly different: it describes cases where a codex-computer-use-* pipe may exist but the client still cannot connect reliably. In this issue's current state, no codex-computer-use-* pipe exists at all.

Current state for this issue:

1. With windows.sandbox = "elevated", node_repl fails with sandbox setup os error 740.
2. Changing to windows.sandbox = "unelevated" and fully restarting Codex recovers nodeRepl.write('ok') and Chrome/browser runtime.
3. Computer Use still fails after that recovery because the native helper/pipe is not created:

Computer Use native pipe is unavailable: Error: failed to connect native pipe: The system cannot find the file specified. (os error 2)

That makes this issue useful as a combined repro showing that the unelevated workaround addresses the node_repl bridge failure but does not necessarily restore Computer Use on Windows.

Additional diagnostics and user-observed context from the affected machine:

Desktop sandbox helper comparison

The Desktop cached sandbox setup helper and the packaged Desktop resource helper are byte-for-byte identical on this installation:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\fb2111b91430cb17\codex-windows-sandbox-setup.exe
C:\Program Files\WindowsApps\OpenAI.Codex_26.602.9276.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe

Both have:

Length: 8376112
SHA256: C1FE23AAAC3439F73CEA122BA703ECE302ACA5BB356CAB8C7FAEB894DF69CC30

A simple string scan of both helpers did not find:

asInvoker
requireAdministrator
requestedExecutionLevel

This seems consistent with the theory discussed in #26530 / #26419 that the Windows Desktop helper may lag the newer npm CLI helper that reportedly contains an asInvoker manifest.

Current pipe state

After switching to:

[windows]
sandbox = "unelevated"

node_repl and browser runtimes are available, but Computer Use still is not. Current named pipes include browser-related pipes only:

codex-browser-use\c6ccffa2-956f-4af3-ac2b-76348d33ef24
codex-browser-use-3fb79a45-6bde-4a1c-8981-89b7bc473f9c
codex-ipc
LOCAL\mojo.plugin_browser_pipe_Default_

No codex-computer-use-* pipe exists, and no codex-computer-use.exe process is running.

Winget/App Installer note

App Installer is installed and healthy according to PowerShell:

Microsoft.DesktopAppInstaller_1.28.240.0_x64__8wekyb3d8bbwe
Status: Ok

The winget.exe App Execution Alias exists at:

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\winget.exe

But invoking winget --version from this Codex shell currently exits without useful output. This may be a shell/session alias issue rather than the primary blocker.

User-observed account/project-sharing context

The user reports that the problem appeared to start after two separate business accounts were linked through some form of shared project/invite relationship. The first meaningful improvement occurred only after the user decoupled the shared project relationship and revoked invites from the personal business account to the company business accounts.

This is only a user-observed correlation, not a proven cause. It may still be relevant if plugin availability, project-scoped permissions, entitlement state, or account/workspace sharing state affects whether Browser/Computer Use runtimes are surfaced or launched by Codex Desktop.

Additional diagnostic: standalone npm Codex CLI comparison.

I installed Node.js LTS and then installed @openai/codex@0.139.0 locally into the workspace only, not globally. This was done to compare the standalone CLI helper against the Desktop helper without replacing Desktop files.

Observed versions:

Node.js: v24.16.0
npm: 11.13.0
@openai/codex: 0.139.0

Helper comparison:

Desktop helper:
C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\fb2111b91430cb17\codex-windows-sandbox-setup.exe
Length: 8376112
SHA256: C1FE23AAAC3439F73CEA122BA703ECE302ACA5BB356CAB8C7FAEB894DF69CC30

npm CLI helper:
<workspace>\outputs\codex-cli-npm\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
Length: 8379696
SHA256: D6349976DAEAEC8539857BA777B807F8565C09512811B4FE0678C1545213B1B1

The npm CLI helper contains:

requestedExecutionLevel level="asInvoker" uiAccess="false"

The Desktop helper did not show asInvoker, requireAdministrator, or requestedExecutionLevel in the same string scan.

The npm CLI codex.exe and codex-windows-sandbox-setup.exe signatures both verified as valid and signed by OpenAI OpCo, LLC.

Installing Node/npm and the standalone CLI did not by itself change the Desktop runtime state. Retest still shows:

{
  "nodeRepl": "ok",
  "extensionBrowser": true,
  "inAppBrowser": true,
  "computerUse": "unavailable",
  "computerUseError": "Computer Use native pipe is unavailable: Error: failed to connect native pipe: The system cannot find the file specified. (os error 2)"
}

Interpretation: this supports the theory from #26530 / #26419 that the standalone CLI helper has the manifest behavior needed to avoid the os error 740 path, while the Desktop helper still appears to lag. It does not by itself resolve the remaining Computer Use native-pipe launch failure.

Update after retesting on a newer Windows Desktop build.

Current environment from the same affected Windows user profile:

Codex AppX package: OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0
Windows sandbox setting: unelevated
WSL-backed app-server config: not set
User profile path contains non-ASCII characters: false
Profiler env vars requested by support: none present
openai-bundled marketplace.json exists: true
Marketplace plugins present: browser, chrome, computer-use, latex, sites
Computer Use plugin cache: openai-bundled/computer-use/26.616.32156
cua_node runtime exists: true
Chrome native host registry entry and manifest exist: true
codex-computer-use-* named pipe exists: true
Browser-related named pipes exist: true

Live node_repl context still does not expose the older expected native-pipe metadata directly:

{
  "hasEnv": true,
  "envKeysMatchingPipe": [],
  "hasNativePipe": false,
  "nativePipeKeys": [],
  "hasConfig": false,
  "requestMetaKeys": [
    "progressToken",
    "threadId",
    "x-codex-turn-metadata"
  ]
}

However, with computer-use@openai-bundled version 26.616.32156, the supported Computer Use bootstrap now succeeds from this same profile:

const { setupComputerUseRuntime } = await import(
  "file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/26.616.32156/scripts/computer-use-client.mjs"
);
const sky = await setupComputerUseRuntime({ globals: globalThis });
const apps = await sky.list_apps();

Observed result:

{
  "ok": true,
  "appCount": 40
}

Chrome extension backend also registers successfully on the same build/profile; a read-only check returned open tabs successfully.

Interpretation: the original os error 740 / elevated sandbox failure remains avoided by windows.sandbox = "unelevated", and the newer bundled Computer Use runtime now appears able to connect when a codex-computer-use-* named pipe exists, even though nodeRepl.nativePipe / SKY_CUA_NATIVE_PIPE_DIRECTORY are still absent from the visible REPL context.

This may indicate that the current Desktop/plugin version fixed or bypassed the native-pipe metadata failure for at least this Windows profile. I am leaving the issue open for now because the earlier failure was persistent across installs and because related Windows reports suggest the problem can vary by user profile, plugin marketplace state, Chrome native-host locks, WSL mode, and runtime relocation state.

Disclosure: I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

This report is useful because it already separates two failure layers: changing windows.sandbox to unelevated restores node_repl + Chrome/browser, but the Computer Use helper/pipe still never appears even though the plugin cache/config remain present.

WinBridge checks that remaining local side as a consistency set — active config, bundled marketplace/plugin generation, cua_node/node_repl, Computer Use helper paths, and related native-host/runtime pointers — with a backup before any repair. That can detect cases where an update/reinstall leaves the visible plugin enabled but the helper/runtime generation is stale or incomplete.

It will not treat changing sandbox mode as a universal fix, and it will not synthesize a privileged Computer Use pipe if Desktop never starts/provisions the helper. If all expected local resources line up but no helper process/pipe is created, that remaining failure should be classified upstream.

If anyone here tries WinBridge after reaching the same partial state (node_repl works, Chrome works, Computer Use pipe missing), please report ✅ / 🟡 / ❌ at https://github.com/zemeng5208/winbridge-recovery/issues/4. Partial results are particularly useful for this case.