Windows Computer Use reuses a stale node_repl exec context across JS calls

Confirming this is still reproducible on Codex App 26.730.8199.0, bundled Computer Use plugin 26.730.61639, @oai/sky 0.6.2, and Windows 10.0.26200 x64. The first Computer Use call succeeds, while the second separate node_repl/js call fails with node_repl exec context not found. Restarting Codex or resetting the JavaScript kernel only restores one successful call before the failure returns. I reproduced it across multiple Windows applications, so it does not appear app-specific.

I’m experiencing the same issue on Windows. Computer Use used to work, but now it can detect open apps without being able to interact with any of them.
Error: node_repl exec context not found
Codex: 26.730.8199.0
Computer Use plugin: 26.730.61639
@oai/sky: 0.6.2
Resetting the Computer Use session did not help.

Tried this on three PCs on Dektop app and CLI, after the first calls, it doesn't survive screenshot and follow up calls. The problem as described is exact and precise.

Update from another Windows task on the same build family: trying to open NetEase Cloud Music through Computer Use failed before reliable desktop interaction with a spawn EPERM error. Retrying and resetting the Computer Use session did not recover sky.list_apps() or sky.list_windows(). This appears to be a separate earlier-stage failure in the Windows helper/runtime path, alongside the stale execution-context failure reported here. Environment: Codex Desktop 26.730.8199.0, Computer Use plugin 26.730.61639, @oai/sky 0.6.2, Windows x64.

Additional clean-machine reproduction after fully reverting all local experiments:

Environment:
- Codex Desktop AppX: 26.730.8199.0 x64
- bundled runner: 0.147.0-alpha.1.2
- Computer Use plugin: 26.730.61639
- @oai/sky: 0.6.2
- runtime: cua_node/fb8898c05a62885e
- Windows 11 Pro 10.0.26200 x64
- config: sandbox_mode="workspace-write", approvals_reviewer="auto_review"
- windows sandbox: elevated, sandbox_private_desktop=false

The runtime was restored to its exact original state. helper_transport.js SHA256:
6423BA834F18139D55CDAC2290C91CD9B24B568332B07CDDD2A7EDA043702B7C

After fully terminating and restarting Codex:

First node_repl/js call:
```js
if (!globalThis.sky) {
  const { sky } = await import("@oai/sky");
  globalThis.sky = sky;
}
globalThis.windows = await sky.list_windows();

Result: succeeds and returns four real desktop windows.

Second independent node_repl/js call:

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

Result:

Error: node_repl exec context not found

This remains reproducible after full app restarts and JS kernel resets. It was also reproduced under frontend Full access and in both projectless and explicit-project tasks, so project membership and sandbox mode are not the root cause.

Two narrow local experiments binding request callbacks to the current Node async context did not fix the behavior and were fully reverted. No local runtime modifications remain.

Additional update from the same Windows machine after the 26.803 desktop update (2026-08-07).

Environment

• Codex Desktop AppX: 26.803.5235.0 x64
• Computer Use bundled plugin: 26.803.41515
• @oai/sky: 0.6.2
• CUA runtime: cua_node/f1bf3cd3a5929acd
• Windows: 10.0.26100 x64
• helper_transport.js SHA256: 6423BA834F18139D55CDAC2290C91CD9B24B568332B07CDDD2A7EDA043702B7C
• node_repl.exe SHA256: BE16C6AF53036D5EAB127C74C726C2513CC66D5584A9EBF4F87909A59338D965

The desktop app and node_repl.exe changed in 26.803, but @oai/sky 0.6.2 and the helper transport hash are unchanged from the failing 26.730 setup.

Fresh minimal reproduction

1. Reset the JavaScript kernel.
2. First independent node_repl/js call imports @oai/sky and runs sky.list_windows(): succeeds and returns 12 real desktop windows.
3. Second independent node_repl/js call selects exactly one normal non-Codex desktop window returned by step 2 and calls read-only sky.get_window_state(...).
4. Result immediately returns:

Error: node_repl exec context not found

No click, typing, launch, or other side-effecting action was attempted.

Permissions, approvals, sandbox, and path cross-check

• This retest ran from a desktop task with an effective Full access / unrestricted filesystem profile and approval prompts disabled.
• The base config is sandbox_mode=workspace-write, approval_policy=never, native Windows sandbox unelevated; the explicit project is trusted.
• The same failure has now been reproduced under both Full access and workspace-write, and in both projectless and explicit-project tasks.
• The failing operation is a read-only state capture before any confirmation-gated input action. No approval or permission prompt appears.
• The sandbox user group has Read and Execute access to the CUA runtime; the current user has Full Control. Both node_repl.exe and codex-computer-use.exe have valid OpenAI Authenticode signatures.
• Codex Desktop, CODEX_HOME, node_repl, and the CUA runtime are all on C:. Only project files are on another local drive; CODEX_HOME is a normal directory, not a junction or symlink.

This makes project membership, project drive, approval policy, filesystem ACLs, and sandbox level unlikely root causes. The evidence still points to the long-lived Windows helper transport retaining an exec context that becomes invalid when the first node_repl/js call ends.

Could the maintainers confirm whether a fix is planned in @oai/sky / the Windows helper transport, and which desktop or plugin build will contain it? I can retest the two-call regression gate immediately when a new build is available.

Me Too

Additional independent reproduction on Windows after a full Codex restart on 2026-08-07. This is blocking a real Computer Use workflow and still reproduces after local configuration issues were corrected.

Reproduction observed

1. Start the target desktop app externally and expose one normal blank window.
2. Fresh Computer Use execution: list_windows() succeeds and finds the unique window.
3. The next independent execution fails with:

Error: node_repl exec context not found

1. Perform the one allowed recovery/reset. In that same execution, rebinding the freshly enumerated window and get_window_state() succeeds and returns a valid screenshot.
2. Move to the next execution and issue one safe click on a blank area.
3. The click call again fails with the same node_repl exec context not found error. Because the call does not return, the input result has to be treated as UNKNOWN and no retry is performed.

This reproduces the exact cross-execution observe → act failure described in this issue.

Isolation already completed

• Full Codex restart performed; new codex.exe, node_repl.exe, Computer Use helper, and native pipe were created.
• A separate bundled-plugin marketplace/config path conflict was fixed first; logs then showed successful bundled plugin registration, but the Computer Use failure remained unchanged.
• The target application is not the cause: it is a normal Windows desktop editor window and the failure occurs before any application-specific operation.
• Plain nodeRepl.write succeeds.
• A standalone 1×1 nodeRepl.emitImage succeeds.
• Window enumeration succeeds.
• Screenshot/state capture can succeed immediately after recovery within the same execution.
• The next independent Computer Use action fails again.
• No repeated resets, custom transport, deprecated transport.close() workaround, or blind single-execution interaction was used.

Impact

This makes the documented safe Computer Use pattern unusable on Windows for stateful GUI work: observe in one execution, stop, act in the next execution, then observe again. The failure occurs at the Computer Use / @oai/sky execution-context lifecycle boundary before reliable input confirmation, so destructive/editor workflows cannot safely continue.

For this reproduction the final state is effectively:

BLOCKED_BY_ENVIRONMENT_POST_RESTART_REPRODUCED

A fix that refreshes/rebinds the Windows helper/native-pipe exec context for every node_repl/js execution while preserving the target window state would unblock the workflow.

Thanks — this is currently a complete blocker for Windows Computer Use automation, and a fix would be greatly appreciated.

Local prototype fix: successful end-to-end validation

I tested a prototype fix locally on Computer Use plugin 26.803.41515, @oai/sky 0.6.2, runtime cua_node/f1bf3cd3a5929acd.

The failure appears to occur because the module-level Windows helper transport dispatches later responses under the async context in which the long-lived helper/stdout listener was originally created. Once that first node_repl/js execution ends, approval or response handling re-enters a stale context.

The working prototype does more than bind the shared callback:

• create an AsyncResource inside each sendRequest();
• store it with that request's pending entry;
• dispatch the matching response—including the approval flow—inside responseResource.runInAsyncScope(...);
• return/await the approval handler instead of detaching it with void;
• call emitDestroy() exactly once on success, rejection, timeout, helper exit, and stdin-write failure.

This preserves the context captured when the request was submitted. It does not disable the active-execution guard, substitute the newest execution ID, or bypass approval.

End-to-end result

After patching only the extracted per-user helper_transport.js and resetting the JavaScript kernel:

1. Execution A imported @oai/sky and called list_apps().
2. Execution B called launch_app() for Gira HS+FS Experte 4.9. The request reached the approval UI, continued after approval, and returned the real launch result. It did not throw node_repl exec context not found.
3. Later independent executions listed/activated a target window, captured desktop and target screenshots, sent a harmless click using the returned screenshot ID, and completed the immediate screenshot refresh.
4. Alt+Tab brought the running Gira application to the foreground and another screenshot succeeded.

Before this change, step 2 failed while handling the helper response/approval in the stale execution context. A reduced AsyncLocalStorage harness also reproduces the failure and passes with the per-request AsyncResource implementation.

One separate limitation remains: Gira launches and is visible in desktop screenshots, but its legacy top-level window is not returned as a directly targetable Computer Use window. Explorer remained targetable, so it was used for the harmless input test. That looks separate from this issue because the cross-execution helper, approval, response, screenshot, and input pipeline now completes.

For integrity, the original helper SHA-256 was 6423BA834F18139D55CDAC2290C91CD9B24B568332B07CDDD2A7EDA043702B7C; the patched local file is 1CB26AACE11DC292F5968F93385E27A35AD5F2840ECE91068C3FE2A40884ED27. The signed executable and AppX payload were not modified.

I can provide the prototype diff and reduced regression harness if useful. An upstream source implementation should add regression coverage for cross-execution observation, approval, input, timeout, helper-exit, rejection, and user-decline paths.

Independent reproduction with additional repair/restart exclusion on the current Store build.

Environment

• Windows 11 x64
• Codex Desktop AppX: OpenAI.Codex 26.803.5235.0
• Bundled Computer Use plugin: 26.803.41515
• Codex CLI: 0.147.0

Repair paths tested before reproduction

• Microsoft Store product 9PLM9XGG6VKS recognized the existing package and reported no newer package available.
• Ran the supported codex plugin remove computer-use@openai-bundled, then codex plugin add computer-use@openai-bundled.
• The rebuilt plugin was installed/enabled at 26.803.41515; all 6 cache files matched the bundled source snapshot byte-for-byte by SHA-256.
• Used a detached helper to stop only executables resolving inside the exact OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0 Store package directory, then relaunched the registered app.
• All 11 pre-restart package process IDs were gone after relaunch; zero survived.

Post-restart result

1. Fresh Node kernel and first Computer Use execution initialized CUA, listed windows, and selected a real Notepad++ window.
2. The immediately following independent execution attempted to activate/refresh/capture that returned window.
3. It failed before input with:

Error: node_repl exec context not found

1. After the one recovery reset, one bounded execution successfully returned three screenshots from the same Notepad++ window.
2. Its next independent follow-up capture failed with the same error.

A plain Node REPL global persisted across separate executions in the control test. No file contents were changed.

This confirms the defect survives a supported plugin cache rebuild plus complete Store-package process replacement. It does not appear to be stale plugin registration, corrupt cached plugin files, or an incomplete desktop-app restart. The one-execution-only behavior remains deterministic on 26.803.5235.0 / 26.803.41515.

Additional reproduction on Windows 11 ARM running in Parallels, after a full Codex Desktop restart on 2026-08-09.

Environment:

• Windows 11 ARM under Parallels
• Computer Use bundled plugin: 26.803.41515
• Target app: Total Commander 10.52 (x64)

Reproduction:

1. Start a fresh node_repl kernel and import @oai/sky.
2. sky.list_windows() succeeds and returns the Total Commander window.
3. sky.get_window({ id, app }) using the exact returned process-backed window succeeds.
4. In the next independent node_repl/js call, sky.activate_window({ window }) fails with:

Error: node_repl exec context not found

1. sky.get_window_state() and sky.press_key() also fail with the same error.

This remains reproducible after the full Codex restart and a JavaScript-kernel reset. The same action-bridge error was also observed with File Explorer, so it does not appear app-specific. The initial list_apps/current-path window mismatch was corrected by using the exact window returned from list_windows(), but the context error remained. No UAC/admin prompt appeared and no files were modified.

Impact: the documented safe observe -> act workflow is blocked before reliable desktop interaction.

Confirming this is still reproducible on the current Windows build, with additional approval-path isolation and an internal feedback upload.

Environment

• Codex Desktop AppX: 26.803.5235.0 x64
• Computer Use plugin: 26.803.41515
• @oai/sky: 0.6.2
• CUA runtime: cua_node/f1bf3cd3a5929acd
• Windows: Microsoft Windows NT 10.0.26200.0 x64
• OpenAI Feedback ID: 019fe97b-865a-7782-9552-07750ebefdc9

A full Codex restart and uninstall/reinstall of the Computer Use plugin did not change the failure. The cached and AppX-bundled CUA runtimes were also byte-identical.

I independently traced the approval-specific path:

1. The helper process and its stdout listener are created during exec A.
2. In exec B, the helper emits approvalRequest.
3. The long-lived stdout callback invokes nodeRepl.config.createElicitation() under the async context captured in exec A.
4. getCurrentExecState() sees stored exec A while activeExecId is B and throws node_repl exec context not found.

A reduced regression test using the real WindowsHelperTransport plus a fake helper fails before a local workaround: the first approved request succeeds, but the second same-app request rejects because another elicitation cannot be created from the stale context. A transport-local workaround that remembers the approved app only after the user accepts and the approved retry succeeds makes that same-app test pass.

Real validation also succeeds across separate executions after the workaround: activate Edge in one execution, then send Ctrl+L in a later execution without the context error.

This workaround is intentionally narrower than an upstream fix and does not address all cross-app, rejection, timeout, or helper-exit paths. The per-request AsyncResource approach described above appears to be the correct general fix. Please correlate this report with the internal Feedback ID above; the local runtime workaround will otherwise be overwritten by the next app/plugin upgrade.

Independent reproduction on Windows confirming this is not Calculator-specific.

Observed behavior

• Computer Use can enumerate installed applications with sky.list_apps().
• Any action that would operate a Windows app fails with:

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

• Calculator was used only as a simple test target. It remained closed after both:
• sky.launch_app({ app: "Microsoft.WindowsCalculator_8wekyb3d8bbwe!App" })
• sky.launch_app({ app: "C:\\Windows\\System32\\calc.exe" })
• The same execution-context failure occurs when targeting an already-running File Explorer window: get_window() can return the exact window, but activate_window() and get_window_state() fail before any UI interaction.
• This therefore blocks control of Windows applications generally, rather than one specific application.

Environment and recovery attempts

• ChatGPT/Codex desktop on Windows
• Computer Use plugin bundle: 26.803.41515
• Reset the persistent JavaScript kernel
• Fully exited/restarted ChatGPT from the system tray
• Uninstalled Computer Use
• Restarted ChatGPT
• Reinstalled Computer Use
• Restarted ChatGPT again

The failure remained unchanged after all of the above.

The installed skill also requires sky.documentation("guidance"), but the loaded sky object has no documentation method (sky.documentation is not a function), which may indicate skill/runtime version skew.

OpenAI Feedback ID: 019fea9b-4c51-7940-be6e-39371f00872d

No personal paths, credentials, or application contents are included in this report.

Correction — current cross-device result (2026-08-10):

The earlier version of this comment incorrectly treated prior successful use on the second Windows PC (“Gigabyte”) as evidence that Computer Use was still working there.

A fresh test on that PC now also fails: the Computer Use graphical environment does not open at all. Therefore:

• There is currently no confirmed working comparison PC.
• The evidence does not support the earlier host-specific conclusion.
• Both Windows PCs are currently affected, although possibly at different stages:
• On the first PC, the plugin can enumerate applications but control/action calls fail with node_repl exec context not found.
• On the Gigabyte PC, the Computer Use graphical environment does not open, so application control cannot begin.
• Calculator remains only a simple test target; this concerns Windows application control generally.

The exact app/plugin/Windows versions and any error output from the Gigabyte PC have not yet been captured, so I am not claiming that both symptoms have the same root cause.

Apologies for the earlier overstatement; this comment has been corrected to reflect the current verified result.

Correction to my earlier cross-device comparison: a fresh test on the second Windows PC (“Gigabyte”) now fails as well—the Computer Use graphical environment does not open, so there is no currently confirmed working comparison machine. I have edited my earlier comment to remove the unsupported host-specific conclusion. The two PCs may still be failing at different stages, and the Gigabyte versions/error details have not yet been captured, so I am not claiming a shared root cause yet.

Successful local validation of the per-request AsyncResource approach on Windows 11 ARM under Parallels.

Environment:

• Codex Desktop AppX: 26.803.5235.0 ARM64
• Computer Use plugin: 26.803.41515
• @oai/sky: 0.6.2
• CUA runtime: cua_node/0daac45fe5a0ff40
• Target: Total Commander 10.52 x64
• Original helper_transport.js SHA-256: 6423BA834F18139D55CDAC2290C91CD9B24B568332B07CDDD2A7EDA043702B7C

Baseline was deterministic after a fresh JS kernel:

1. Exec A: list_windows() and get_window() succeeded.
2. Exec B: read-only get_window_state() failed immediately with node_repl exec context not found.

I patched only the extracted per-user @oai/sky JavaScript helper to:

• create one AsyncResource per request;
• store it on the pending request;
• dispatch the matching response, including approval handling, via runInAsyncScope(...);
• return/wait for the approval handler;
• call emitDestroy() once on success, rejection, timeout, helper exit, and stdin-write failure.

The active-execution guard and approval flow were not bypassed. Signed executables and the AppX payload were untouched. Patched helper SHA-256: 49AD10E22F755CC4103CB4E9DA50C3F8EE4CF0D304CCD681C041B5066A4823A6.

Post-patch regression:

1. Reset JS kernel.
2. Exec A listed/rebound the Total Commander window.
3. Exec B reached the real window-state result (initially reported that the window was minimized) instead of the context error.
4. Exec C activated Total Commander successfully.
5. Many later independent executions repeatedly read accessibility state and sent keyboard input without the context error.
6. Through Total Commander itself, selected README.md, opened its F5 copy dialog, entered a dedicated destination, and completed the copy.
7. Source and destination were both 3251 bytes and had identical SHA-256: 0BF9B7586D7688D2EF43B49B1D56EFDF080E1C1C48294BC738AC687C7048BDD6.

A separate screenshot/WGC attempt returned FrameArrived timed out: timed out waiting on channel, while accessibility-based state and input continued to work. That appears independent of the stale exec-context defect.

This is still a local extracted-runtime patch and may be overwritten by an app/runtime update, but it confirms the per-request AsyncResource design fixes the real cross-execution Computer Use flow on ARM64 as well.

Update after installing the newer Windows Store build: the stale cross-execution context defect appears fixed on this machine.

Environment

• Windows 11 x64, build 26200.8973
• Codex Desktop AppX: OpenAI.Codex 26.803.8161.0 (Status: Ok)
• Bundled Computer Use plugin cache: 26.803.61601
• @oai/sky: 0.6.6
• Codex CLI: 0.147.0
• Current AppX helper_transport.js SHA-256: 7BC54C5BB7F49661FB1F501C6832F5490620501464D3F1593A361A85C7F66B39
• No AppX, plugin, or runtime files were patched.

For comparison, my earlier deterministic reproduction was on Desktop 26.803.5235.0, Computer Use 26.803.41515, and @oai/sky 0.6.2.

Cross-execution regression result

I reused the existing @oai/sky session without resetting the JavaScript kernel. The session and ordinary variables survived an actual user reply, which covers the post-user-turn reacquisition case that previously remained unverified.

I then ran dozens of independent node_repl/js executions, including a dedicated 12-call repeated get_window_state() stress sequence. The separate calls successfully completed:

1. list_apps() / list_windows()
2. get_window() rebinding
3. visible and occluded screenshots plus accessibility capture
4. activate_window()
5. element and coordinate clicks
6. press_key() and type_text()
7. scroll and drag with screenshot IDs
8. minimize detection, activation, refresh, and capture after restore
9. close, verify removal, launch_app(), rediscover, recapture, and close again
10. capture/accessibility checks against a disposable WinForms harness and Notepad++

There were zero occurrences of:

node_repl exec context not found

This includes the exact previously failing pattern: observe in one execution, act in later executions, and refresh/verify in still later executions. The Store update changed the helper hash from the earlier baseline, although the new minified helper does not contain the prototype AsyncResource marker strings, so I am not inferring the exact upstream implementation.

Separate remaining defects/limitations

These did not reproduce the stale-context error and appear independent of this issue:

1. The bundled skill still requires sky.documentation("guidance"), ("api"), and ("confirmations"), but live @oai/sky 0.6.6 still has no documentation member.
2. set_value() failed twice on a standard WinForms text box with:

``text
read UIA value read-only state: Requested property was not in the CacheRequest (0x80070057)
``

Element click + Ctrl+A + type_text() worked, and an independent harness state file verified the exact typed value.

1. After scrolling, get_window_state() returned accessibility index 2315 for a visible list item, but using that index in the next execution failed with:

``text
element 2315 is not available in cached app state for ComputerUseHarness.exe
``

Using a high returned index within the same execution worked, and a coordinate click from the prior screenshot also worked across executions.

1. One occluded capture returned foreground Chrome pixels while the accessibility payload correctly identified the target harness. A later controlled occlusion by another native window captured the harness correctly, so screenshot targeting may still be intermittent.

Conclusion

On 26.803.8161.0 / @oai/sky 0.6.6, the original stale node_repl execution-context defect is no longer reproducible in same-turn, multi-call, app lifecycle, or post-user-reply testing. This is strong evidence that the fix for #37013 shipped in this update. The remaining items above look suitable for separate follow-up issues rather than reasons to keep classifying the original transport bug as present.

Update after installing the newer Windows Store build: the stale cross-execution context defect appears fixed on this machine. ### Environment - Windows 11 x64, build 26200.8973 - Codex Desktop AppX: OpenAI.Codex 26.803.8161.0 (Status: Ok) - Bundled Computer Use plugin cache: 26.803.61601 - @oai/sky: 0.6.6 - Codex CLI: 0.147.0 - Current AppX helper_transport.js SHA-256: 7BC54C5BB7F49661FB1F501C6832F5490620501464D3F1593A361A85C7F66B39 - No AppX, plugin, or runtime files were patched. For comparison, my earlier deterministic reproduction was on Desktop 26.803.5235.0, Computer Use 26.803.41515, and @oai/sky 0.6.2. ### Cross-execution regression result I reused the existing @oai/sky session without resetting the JavaScript kernel. The session and ordinary variables survived an actual user reply, which covers the post-user-turn reacquisition case that previously remained unverified. I then ran dozens of independent node_repl/js executions, including a dedicated 12-call repeated get_window_state() stress sequence. The separate calls successfully completed: 1. list_apps() / list_windows() 2. get_window() rebinding 3. visible and occluded screenshots plus accessibility capture 4. activate_window() 5. element and coordinate clicks 6. press_key() and type_text() 7. scroll and drag with screenshot IDs 8. minimize detection, activation, refresh, and capture after restore 9. close, verify removal, launch_app(), rediscover, recapture, and close again 10. capture/accessibility checks against a disposable WinForms harness and Notepad++ There were zero occurrences of: ``text node_repl exec context not found ` This includes the exact previously failing pattern: observe in one execution, act in later executions, and refresh/verify in still later executions. The Store update changed the helper hash from the earlier baseline, although the new minified helper does not contain the prototype AsyncResource marker strings, so I am not inferring the exact upstream implementation. ### Separate remaining defects/limitations These did not reproduce the stale-context error and appear independent of this issue: 1. The bundled skill still requires sky.documentation("guidance"), ("api"), and ("confirmations"), but live @oai/sky 0.6.6 still has no documentation member. 2. set_value() failed twice on a standard WinForms text box with: `text read UIA value read-only state: Requested property was not in the CacheRequest (0x80070057) ` Element click + Ctrl+A + type_text() worked, and an independent harness state file verified the exact typed value. 3. After scrolling, get_window_state() returned accessibility index 2315 for a visible list item, but using that index in the next execution failed with: `text element 2315 is not available in cached app state for ComputerUseHarness.exe ` Using a high returned index within the same execution worked, and a coordinate click from the prior screenshot also worked across executions. 4. One occluded capture returned foreground Chrome pixels while the accessibility payload correctly identified the target harness. A later controlled occlusion by another native window captured the harness correctly, so screenshot targeting may still be intermittent. ### Conclusion On 26.803.8161.0 / @oai/sky 0.6.6, the original stale node_repl` execution-context defect is no longer reproducible in same-turn, multi-call, app lifecycle, or post-user-reply testing. This is strong evidence that the fix for #37013 shipped in this update. The remaining items above look suitable for separate follow-up issues rather than reasons to keep classifying the original transport bug as present.

Upgrading to the windows version posted today fixed this issue for me.

Following up on my two earlier reports in this thread — both the stale exec-context failure and the spawn EPERM observation are gone on the current build.

Environment

• Codex Desktop AppX: 26.803.10989.0 x64 (was 26.730.8199.0 when I first confirmed)
• Computer Use plugin: 26.803.81509
• @oai/sky: 0.6.6
• CUA runtime: cua_node/23828fd353da361d, freshly extracted by the update
• Windows 10.0.26200 x64

helper_transport.js changed

| build | size | SHA-256 |
|---|---|---|
| 0.6.2 | 9305 | 6423BA834F18139D55CDAC2290C91CD9B24B568332B07CDDD2A7EDA043702B7C |
| 0.6.6 | 9182 | 7BC54C5BB7F49661FB1F501C6832F5490620501464D3F1593A361A85C7F66B39 |

The extracted runtime matches the AppX copy byte for byte, so this is a stock install with no local modifications.

Regression gate passes

Fresh JS kernel, three strictly independent node_repl/js calls:

1. list_windows() -> pick a normal desktop window -> activate_window -> get_window -> store on globalThis. Result: {"found":true}
2. Separate call: get_window_state(..., include_screenshot: true) on the window from call 1. Result: ["window","screenshots","accessibility"]
3. Separate call: sky.click() referencing the screenshotId produced in call 2. Result: {"clicked":true,"screenshotId":"screenshot-0","x":347,"y":449}

No node_repl exec context not found at any point.

The spawn EPERM I reported on Aug 6 is also gone. A cold start of the same application now returns {"launched":true}, and a separate independent call afterwards returns {"appCount":40,"windowCount":6} — list_apps() and list_windows() both work, which they did not after the failure I originally described.

One detail worth highlighting for anyone verifying this themselves

The screenshot id created in call 2 is still valid in call 3. A fix that merely tears down and respawns the helper per execution would pass the original two-call gate but fail here, because the screenshot registry lives in the helper process. This build preserves it, so the documented observe-then-act workflow works end to end.

Update and guarded recovery reference: I published an audit-first, exact-fingerprint kit here:

https://github.com/fyliuuuuuu-dev/codex-windows-computer-use-recovery

Use the security-hardened release: https://github.com/fyliuuuuuu-dev/codex-windows-computer-use-recovery/releases/tag/v1.0.1 (v1.0.0 is superseded).

Current local result on 2026-08-11: stock AppX 26.803.8161.0, Computer Use 26.803.61601, @oai/sky 0.6.6, helper SHA-256 7BC54C5BB7F49661FB1F501C6832F5490620501464D3F1593A361A85C7F66B39 passed separate window/state calls, a cross-execution screenshotId click, post-action refresh, and five further independent state reads with zero node_repl exec context not found errors.

Important boundary: the repository treats 0.6.6 as an upstream-fix candidate and does not patch it. The legacy workaround is available only for the exact live-runtime @oai/sky@0.6.2 helper/package fingerprint, after full quit, dry run, signed-runtime verification, and backup; unknown builds and untrusted paths are refused. It includes no complete bundled OpenAI helper file or binary.

@netman2048 @jiangyuShiro, you recently reported the same symptom or update result in this thread. Sharing this only as a diagnostic and rollback reference. On current 0.6.6 builds, please use the inspector/regression gate and do not apply the legacy patch.

This issue is still open, so the repository describes community evidence rather than maintainer-confirmed guidance. The missing sky.documentation() API on 0.6.6 is recorded as a separate defect.

Follow-up to my earlier report in https://github.com/openai/codex/issues/37013#issuecomment-5237481370: the issue is now resolved on this Beelink after installing the current Microsoft Store update.

Working environment

• Codex Desktop AppX: OpenAI.Codex 26.803.10989.0
• Computer Use plugin: 26.803.81509
• Stock installation; no runtime files patched

Verification

Computer Use successfully completed the previously failing observe-then-act workflow across separate node_repl/js executions:

1. Located the Windows Calculator window.
2. Attached to and activated it in later calls.
3. Clicked C, then entered 7 × 8 =.
4. Refreshed the window state and verified that the visible result was 56.

There were no occurrences of node_repl exec context not found.

Calculator was only the simple test target: the original failure prevented interaction with Windows applications generally. Uninstalling/reinstalling the Computer Use plugin and restarting the desktop app had not fixed the earlier build; updating the desktop app through Microsoft Store did.

OpenAI Feedback ID: 019fea9b-4c51-7940-be6e-39371f00872d