Windows Computer Use approval prompt never appears; launch_app fails with `node_repl exec context not found`

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

• #37013

Powered by Codex Action

Additional confirmed reproduction on Windows 11 ARM64 under Parallels Desktop.

Environment

• Host: macOS + Parallels Desktop
• Guest: Windows 11 Pro 10.0.26200 ARM64
• Codex desktop package: OpenAI.Codex_26.730.8199.0_arm64
• Computer Use plugin: computer-use@openai-bundled 26.730.61639
• @oai/sky: 0.6.2
• Windows native helper process and named pipe are present and running

Exact reproduction

Notepad was opened manually first. Computer Use then used the exact values returned by list_windows():

app:

Additional diagnostics from a Windows 11 ARM64 guest under Parallels Desktop narrow this further to node_repl execution-context management rather than helper crash or ARM emulation failure.

Environment:

• Windows 11 Pro 10.0.26200 ARM64
• Codex Desktop 26.730.8199.0 (ARM64 AppX)
• Computer Use plugin 26.730.61639
• @oai/sky 0.6.2
• Runtime launches the x64 codex-computer-use.exe under ARM64 emulation; an ARM64 helper is present but unused

Latest deterministic sequence (JST):

• 15:39:39 sky.list_windows() succeeds
• 15:39:47 sky.get_window({id:592174}) succeeds for Notepad
• 15:39:58.493 sky.activate_window({window:{app:"Microsoft.WindowsNotepad_8wekyb3d8bbwe!App",id:592174}}) fails with Error: node_repl exec context not found
• No approval dialog appears

Helper crash checks:

• The helper process involved in the failure started at 15:39:39 and was still running more than 20 minutes later
• Its parent node.exe and parent node_repl.exe were also still running
• No replacement helper started after the error
• No matching Application Error, WER, Reliability Monitor, Crashpad, or crash-dump record exists for any failure timestamp
• No codex-computer-use.exe, node_repl.exe, or node.exe crash/hang event was recorded

Important correlation:

• %USERPROFILE%\.codex\node_repl\active_execs had a modification timestamp exactly matching the failure second (15:39:58)
• The directory was empty afterward

This strongly suggests that the execution-context registration is being removed or lost while the helper and all related processes remain alive. The failure is therefore not consistent with helper crash, ARM64 emulation crash, Parallels-specific failure, or window enumeration failure.

Also confirmed separately:

• Adding Notepad to the app’s real computer_use.windows.always_allowed_app_ids Boolean-map config was parsed correctly by the installed desktop app, survived restart, and still did not change the failure
• The test approval entry was then removed cleanly

Current best-fit diagnosis: node_repl execution-context bookkeeping or the helper-to-node_repl context handoff fails specifically on intervention calls such as activate_window, get_window_state, and launch_app, while enumeration/read-only calls continue to work.

Related observation from the same Windows app/plugin build family: in another task, attempting to open NetEase Cloud Music also failed before a usable approval or launch flow, with spawn EPERM; retries and resetting the Computer Use session did not restore app/window enumeration. This is not the identical error reported here, but it suggests the approval/launch path can be affected by an earlier native helper failure. Environment: Codex Desktop 26.730.8199.0, Computer Use plugin 26.730.61639, @oai/sky 0.6.2, Windows x64.

Additional independent reproduction on the same Windows app/plugin build:

Environment

• Codex Windows package: 26.730.8199.0
• Computer Use plugin: 26.730.61639
• Bundled @oai/sky: 0.6.2
• Native Windows runtime (not WSL)

Additional targets and results

The failure is not specific to Paint or to one desktop application:

1. sky.list_apps() succeeds and returns the installed application catalog.
2. Microsoft Edge is found as MSEdge, but sky.launch_app({ app: "MSEdge" }) fails immediately with:

``text
Error: node_repl exec context not found
``

1. RStudio is also discovered in the application catalog. After a full Windows reboot, attempting to launch the exact returned RStudio app ID fails with the same error.
2. In earlier sessions, an already-running RStudio window could be discovered/bound, but get_window_state(), screenshot-backed inspection, activation, and keyboard input all failed at the same execution-context layer.

Recovery attempts

• Complete Codex restart
• Full Windows reboot
• Windows app Repair
• Resetting the Node REPL kernel
• Removing residual node_repl / Computer Use processes before restart
• Hash comparison of the packaged and extracted runtime files

None changed the behavior. The full reboot confirms this is not only a stale orphan-process condition.

API-contract signal

The currently materialized Computer Use SKILL.md requires await sky.documentation("guidance") before control and refers to sky.documentation("api") / sky.documentation("confirmations"). However, after importing the bundled @oai/sky 0.6.2:

typeof sky.documentation // "undefined"
typeof sky.list_apps     // "function"

This may be a separate packaging/API-version mismatch rather than the direct cause of the missing exec context, but it is present on the same affected build and may help identify a mismatched skill/runtime bundle.

No user names, local project paths, pipe identifiers, credentials, or application contents are included here.

Additional evidence suggests this is broader than only the approval-prompt callback.

On 26.730.8199.0 / Computer Use 26.730.61639 / @oai/sky 0.6.2:

1. sky.list_windows() succeeds in the first node_repl/js execution.
2. sky.launch_app(notepad.exe) in the next execution fails immediately with:

Error: node_repl exec context not found

1. No reliable approval UI appears.
2. The same failure remains when the app may already be approved, suggesting that ordinary request completion/intervention handling can also lose the active exec context.
3. Full access, workspace-write, projectless tasks, explicit-project tasks, JS reset, and complete Codex restart do not change the result.

Current request metadata is populated rather than empty:

• model: gpt-5.6-sol
• sandbox: windows_elevated
• workspace_kind: projectless

The helper remains alive under 550W\CodexSandboxOffline. The observed failure is therefore consistent with execution-context bookkeeping/handoff rather than a helper crash.

sky.launch_app() fails with Error: node_repl exec context not found on Windows

Summary

The bundled Computer Use plugin can successfully initialize @oai/sky and call read-only methods such as sky.list_apps() and sky.list_windows(). However, calling sky.launch_app() immediately fails with:

Error: node_repl exec context not found

The requested application is not launched. Resetting the persistent Node REPL kernel and reinitializing @oai/sky does not resolve the issue.

Environment

• Codex desktop app: 26.803.5235.0 (OpenAI.Codex, x64)
• Computer Use plugin: 26.803.41515
• Operating system: Windows 11 Enterprise LTSC, 64-bit
• OS version/build: 10.0.26100 / 26100
• PowerShell: 7.6.4
• Date observed: 2026-08-07
• Computer Use package: bundled @oai/sky, invoked through the persistent mcp__node_repl__js kernel

Steps to reproduce

1. Start a fresh Node REPL session.
2. Initialize the bundled Computer Use API:

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

1. Confirm that the helper responds normally:

``js
globalThis.apps = await sky.list_apps();
nodeRepl.write(JSON.stringify(apps, null, 2));
``

list_apps() returns the installed/running applications successfully.

1. Attempt to launch File Explorer using an explicit executable path:

``js
await sky.launch_app({ app: "C:\\Windows\\explorer.exe" });
nodeRepl.write("launch request completed");
``

Actual result

The call fails immediately:

Error: node_repl exec context not found

A subsequent sky.list_windows() call succeeds but shows that no File Explorer window was created.

The same error was also observed with these identifiers:

await sky.launch_app({ app: "explorer.exe" });
await sky.launch_app({ app: "process:C:\\Windows\\explorer.exe" });

Expected result

sky.launch_app() should launch File Explorer and resolve normally. The new window should then be discoverable through sky.list_apps() or sky.list_windows() so it can be selected for further Computer Use actions.

Recovery attempts

• Retried launch_app() with the full executable path, executable name, and process: identifier.
• Confirmed that sky.list_apps() and sky.list_windows() remained functional after the error.
• Reset the persistent JavaScript kernel using mcp__node_repl__js_reset.
• Re-imported @oai/sky and confirmed that list_apps() still worked.
• Retried sky.launch_app({ app: "C:\\Windows\\explorer.exe" }) after the reset.

The post-reset attempt failed with the same error.

Reproduction frequency

Reproduced on every attempted sky.launch_app() call in this session, including after a full Node REPL reset.

Impact

Computer Use cannot open an application that does not already expose a targetable window. This blocks workflows that depend on launching File Explorer or another closed application before selecting its window.

Additional notes

• The failure appears specific to the launch path in this session; read-only discovery calls remain responsive.
• No Windows terminal, Run dialog, or alternative UI automation mechanism was used.
• User-specific paths and unrelated window titles have been omitted from this report.

Possibly the same defect as #37281 — cross-linking rather than duplicating.

We posted a root-cause analysis there: #37281 (comment).
Short version: the Computer Use helper transport stays bound to the AsyncLocalStorage exec
context that spawned it, so a callback from the helper back into the kernel resolves against an
exec that has already ended.

node_repl.exe has two throw sites behind this one error string, which may be why this
issue and #37281 read like different bugs:

| Site | Condition | Symptom |
|---|---|---|
| execState == null | no store at all — a callback outside any exec | this issue: fails on the first launch_app, in the approval/elicitation callback |
| execState.id !== activeExecId | store exists, belongs to a prior exec | #37281: succeeds once, fails on subsequent calls |

To be clear about what we did and didn't verify: we reproduced and fixed the second row. The
mapping of this issue to the first row is an inference from the report here plus the two
shipped throw sites — we did not reproduce the launch_app first-call path. So the workaround
in that comment (await sky.transport.close() before Computer Use work in each new JS call)
may or may not help here. Worth trying, and worth reporting back either way — a negative result
would usefully separate the two.

Possible workaround / observation

I noticed a potentially useful workaround for this issue.
After sending Computer Use an instruction to interact with a specific application, if I manually bring the target application's window to the foreground and leave it visible on screen for a few seconds, Computer Use is sometimes able to start interacting with the application normally.
In other words, the sequence that works for me is roughly:

1. Ask Computer Use to perform an action in a specific application.
2. Manually bring that application's window to the foreground.
3. Leave the window visible and focused for a few seconds.
4. Computer Use then starts interacting with it normally.

I have reproduced this behavior multiple times on my Windows machine.
This is only an observation/workaround rather than a confirmed explanation of the underlying issue, but it may suggest that window visibility, foreground focus, or target-window acquisition timing is involved in the failure.
It would be interesting to know whether others affected by this issue can reproduce the same behavior.

I kept Slack open but I continued to get the error. So, the workaround did not work for me

Additional reproduction on a newer Windows build.

Feedback ID:019fe5bf-6666-7143-bf64-f74190827115
In-app feedback with reproducing session logs:

Environment:

• Codex App: OpenAI.Codex 26.803.5235.0
• Computer Use plugin: 26.803.41515
• @oai/sky: 0.6.2
• cua_node: f1bf3cd3a5929acd
• Windows 11 Home 25H2, OS Build 26200.8875, x64

Observed behavior:

• sky.list_apps() succeeds.
• sky.list_windows() succeeds.
• sky.get_window() succeeds.
• sky.launch_app() fails with node_repl exec context not found in helper_transport.js.
• sky.get_window_state() fails with the same error.
• Desktop logs report computer-use native pipe startup ready.
• No sandbox failure, os error 740, missing helper-path error, or Node-version error was observed.

Recovery attempts:

• Full Windows/Desktop restart and a new task/thread.
• Windows App Repair.
• Rematerialized the Computer Use plugin cache.
• Rematerialized the bundled marketplace, plugin cache, cua_node runtime, and node_repl state.

The regenerated node_repl.exe, node.exe, @oai/sky/package.json, and helper_transport.js were verified SHA-256 identical to the previous copies, and the same failure persists.

This therefore appears to still reproduce on 26.803.5235.0, and does not look like a simple stale/corrupted local runtime.

I can reproduce the same error on a newer Codex Desktop and Computer Use build. I also found a reproduction that does not call launch_app() and does not request an approval.

Current environment

• Codex Desktop: 26.803.5235.0 (Microsoft Store package)
• Bundled Computer Use plugin: 26.803.41515
• OS: Windows 11 Pro, 10.0.26200, build 26200, 64-bit
• Runtime mode: Windows native, not WSL
• Computer: ASUS desktop
• CPU: 12th Gen Intel Core i5-12400F
• Memory: 32 GB
• Codex installation drive: C:
• C:: 1 TB NVMe SSD, NTFS (932 GB reported capacity)
• D:: Kingston A400 480 GB SATA SSD, NTFS (447 GB reported capacity)

Reproduction after reinstall and restart

I reset the persistent Node REPL and then ran these as separate tool calls.

First tool call:

const { sky } = await import("@oai/sky");
const apps = await sky.list_apps(); // succeeds; 40 apps
const chrome = apps.find(app => app.id === "Chrome");
const window = await sky.get_window({
  id: chrome.windows[0].id,
  app: chrome.windows[0].app
});
const state1 = await sky.get_window_state({
  window,
  include_screenshot: false,
  include_text: true
});

Result: success. The accessibility tree contained 230,522 characters.

Second, separate tool call using the saved sky and window:

const state2 = await sky.get_window_state({
  window,
  include_screenshot: false,
  include_text: true
});

Result:

Error: node_repl exec context not found

A third, separate control call to sky.list_apps() succeeded again and returned 40 apps. This indicates that the Computer Use service and native helper were still active after the failure.

What this adds

The failure is not limited to launch_app() or to an approval-required action. A read-only get_window_state() operation succeeds in the first Node REPL execution context, but the same operation fails in the next execution context. Two state captures performed inside one tool call have succeeded in earlier testing.

The behavior remained after:

• Restarting Codex Desktop
• Restarting Computer Use
• Reinstalling the Computer Use plugin
• Starting from a fresh Node REPL state

This looks like an execution-context lifetime or handoff defect between separate Node REPL tool calls. Personal paths, window titles, and task identifiers are omitted.

Update from x64 on the current build.

• Codex Desktop AppX: 26.803.10989.0 x64
• Computer Use plugin: 26.803.81509
• @oai/sky: 0.6.6 (was 0.6.2)
• Windows 10.0.26200 x64, stock install

The node_repl exec context not found failure no longer reproduces here. The reported sequence now completes across strictly independent node_repl/js executions:

• call 1: list_windows() -> activate_window -> get_window -> {"found":true}
• call 2 (separate): get_window_state(..., include_screenshot: true) -> ["window","screenshots","accessibility"]
• call 3 (separate): sky.click() using the screenshot id produced in call 2 -> {"clicked":true,"screenshotId":"screenshot-0","x":347,"y":449}

activate_window, get_window_state and launch_app — the three intervention calls named in the best-fit diagnosis above — all work, including across execution boundaries. Full test details in #37013.

My earlier spawn EPERM observation also no longer reproduces. A cold start of the same desktop app now returns {"launched":true}, and a subsequent independent call returns {"appCount":40,"windowCount":6}.

Scope caveat: this is a native x64 report. The original report here is ARM64 running the x64 codex-computer-use.exe under emulation, so I cannot speak to that path — someone on ARM64 should confirm separately before this is considered resolved.