Repository navigation
Computer Use native pipe unavailable on Windows despite codex-computer-use pipe existing #26528
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.602.3474.0 (observed app path: C:\Program Files\WindowsApps\OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0\app\Codex.exe)
What subscription do you have?
Unknown / not specified
What platform is your computer?
Windows
What issue are you seeing?
Computer Use cannot reliably list or control open Windows windows in the Codex desktop app on Windows. The failure appears related to Codex session/runtime wiring for the Computer Use native pipe.
The user approved the Codex prompt:
Set up Agent sandbox to continue / Protect your files and control network access
Computer Use still repeatedly failed to run sky.list_windows(). After reverting/ignoring that setup and restarting Codex, the app again showed the setup banner, but Computer Use still failed. This created a loop where enabling sandbox setup, disabling/ignoring it, and restarting Codex did not restore Computer Use.
Main error:
Computer Use native pipe is unavailable: Error: failed to connect native pipe: The system cannot find the file specified. (os error 2)
Latest stack trace:
Error: Computer Use native pipe is unavailable: Error: failed to connect native pipe: The system cannot find the file specified. (os error 2)
at NativePipeComputerUseTransport.create (C:\Users\duane\.codex\plugins\cache\openai-bundled\computer-use\26.602.30954\scripts\computer-use-client.mjs:59:13)
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
at async setupComputerUseRuntime (C:\Users\duane\.codex\plugins\cache\openai-bundled\computer-use\26.602.30954\scripts\computer-use-client.mjs:19:16)
What steps can reproduce the bug?
- Load the Computer Use skill instructions.
- Run the supported bootstrap:
const { setupComputerUseRuntime } = await import(
"C:/Users/duane/.codex/plugins/cache/openai-bundled/computer-use/26.602.30954/scripts/computer-use-client.mjs"
);
globalThis.sky = await setupComputerUseRuntime({ globals: globalThis });
await sky.list_windows();- Observe the native pipe connection failure.
- Reset the JS runtime and retry.
- Restart the Codex desktop app and retry the same bootstrap.
- Confirm the Computer Use plugin files exist, including
scripts/computer-use-client.mjs. - Check Windows named pipes.
Important observation: after restarting Codex and retrying, Windows showed a live-looking Computer Use named pipe such as:
codex-computer-use-c3bfbf4e-ab76-4b7b-8a6c-c5360d305cc5
Earlier, another session also showed:
codex-computer-use-3f04fac9-21c7-437c-9de6-c37a50f8fdf4
So a codex-computer-use-* pipe appears to exist, but the Computer Use client still fails to connect.
What is the expected behavior?
Computer Use should successfully run:
await sky.list_windows();and return the list of currently open Windows windows.
Additional information
Environment observed:
- OS: Windows
- Date of latest retry: June 5, 2026
- Codex app path observed:
C:\Program Files\WindowsApps\OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0\app\Codex.exe - Computer Use plugin path:
C:\Users\duane\.codex\plugins\cache\openai-bundled\computer-use\26.602.30954 - Required client file exists:
scripts\computer-use-client.mjs
Runtime metadata observed earlier:
{
"hasNativePipe": false,
"hasCreateConnection": "undefined",
"skyPipeDirectory": null,
"sandbox": "none"
}The runtime object was also locked:
{
"envExtensible": false,
"nodeReplDescriptor": {
"writable": false,
"configurable": false
}
}At one point, Computer Use briefly worked enough to list Chrome windows, including New Issue - Google Chrome, but when attempting to inspect the GitHub issue page, Computer Use stopped 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.
Suspected cause: the Computer Use helper/pipe may be running, but the Codex session/runtime is not receiving or using the correct native pipe metadata, such as nodeRepl.nativePipe or SKY_CUA_NATIVE_PIPE_DIRECTORY, or it receives an unusable/stale native pipe path.
Please also clarify whether the "Set up Agent sandbox..." state is required for Computer Use, incompatible with Computer Use, or unrelated, since both enabling and disabling/ignoring it have led to repeated Computer Use failures in this user's sessions.
Latest update, June 5, 2026:
After the original failures, Computer Use later started working without any obvious user-side fix. In the same Codex session, it successfully ran sky.list_windows() and returned open windows including:
New Issue - Google ChromeChat | (no title) | Personal | duane.niu@gmail.com | Microsoft TeamsGoogle Chrome
Computer Use was then able to control Chrome enough to fill out this GitHub issue form.
However, shortly afterward it became unstable again: sky.list_windows() still succeeded and returned the Chrome windows, but attempting to activate the GitHub issue window failed repeatedly with:
Error: failed to activate captured window
A later retry then activated the same window again. This suggests the bug is intermittent/session-state dependent rather than a simple missing install or permanently broken setup. The native pipe/helper may sometimes be available enough to list windows, but not reliably usable for activation/control, or the session may lose and regain valid native-pipe/window-control state after initially working.
Activity
github-actions commentedon Jun 5, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
nodeRepl.nativePipeundefined, native pipe path unavailable #26329Powered by Codex Action
stevenworld75 commentedon Jun 20, 2026
Sharing the workaround that fixed this class of Computer Use failure on my Windows desktop. This is not an official OpenAI fix.
My local finding: the expected codex-computer-use-* native pipe was absent, but the bundled helper binary itself was healthy when used over stdio:
ode_modules/@oai/sky/bin/windows/codex-computer-use.exe
What fixed it locally was patching the bundled computer-use-client.mjs so Windows setup does this:
On the same machine I also had the
ode_repl sandboxPolicy regression, so the full write-up includes both repairs plus an idempotent repair script and restart watchdog.
Verification:
Full copy/paste prompt and repair notes:
https://gist.github.com/stevenworld75/6c59315b858807a1b6d6a238b1db69f6
Use carefully: back up first, discover local paths dynamically, and only apply the Computer Use client patch to the plugin version it was built for.
DokPlay commentedon Jul 1, 2026
Adding another data point from my Windows setup.
In my case, Computer Use itself does not appear to be completely broken: it can list apps/windows, and it can operate another browser window successfully. For example, the same workflow works in Sun Browser.
The failure seems specific to Google Chrome.
Environment:
26.623.70822openai-bundled/computer-use/26.623.70822openai-bundled/chrome/26.623.708221.1.5Default149.0.7827.20110.0.26200x64What works:
sky.list_apps()worksWhat fails:
When targeting the Chrome window, Computer Use stops at
get_window_state()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.I also checked the Chrome extension/native host setup:
com.openai.codexextension.jsonexistsextension-host.exeexistschrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/So this does not look like a general native pipe failure in my case. The native pipe / Computer Use path works for other apps and another browser. The breakage seems to be specifically in the Chrome URL-confidence / window-to-tab URL detection path on Windows.
d-b-c-e commentedon Oct 17, 2026
Additional Windows observations from October 17, 2026, including an old-session versus fresh-session comparison. This may help narrow session initialization/recovery; it does not establish a root cause.
Environment
Observed sequence
Two existing VS Code CLI sessions successfully imported @oai/sky, but
sky.list_windows()failed with:Resetting the coordinator's node kernel, reimporting, and retrying did not fix it.
Fresh standalone Windows Terminal sessions using the same CLI successfully listed windows. The old sessions still failed afterward. The original CLI sessions started before ChatGPT; the successful fresh sessions started after ChatGPT. All checked processes were in the same interactive Windows session. Terminal host and startup timing are confounded: this is not proof that VS Code causes the issue.
In a fresh standalone session, Calculator launched after the native permission prompt was resolved. Capture returned a 322x534 image with a Calculator title bar but terminal content covering the client area, and accessibility was null.
activate_windowfailed withfailed to activate captured window, including one retry after refreshing the selected window. No input was sent; successful listing did not establish usable control.Separately, the user saw
Computer Use helper already has an active requestwhile the Calculator permission request was pending. Overlapping requests may explain that occurrence; we have not established a persistent lock or a common cause with the transport/activation failures.The supported initialization used was:
No manual helper launch, pipe override, private protocol client, automated permission approval, or alternative input workaround was used. Shell operations continued to work.
Expected behavior / useful investigation
Existing sessions should establish or recover their native connection when ChatGPT becomes available, or return a precise supported recovery instruction. A successful window listing should be distinguishable from actual capture/activation capability. Pending app approvals should identify the owning request so another session can avoid conflicting calls.
The planned follow-up is to update/open ChatGPT first, start one fresh CLI session, serialize requests, and test enumeration, correct capture, activation, and a harmless Calculator operation. Only then compare a fresh VS Code session. These are observed failures and a proposed isolation test, not a clean-install deterministic reproduction.
This report intentionally excludes private repositories, local account paths, full session transcripts, screenshots of unrelated windows, and credentials. Related lifecycle/recovery discussion: #50876.