[Critical][Windows] Recurring local execution failure: PowerShell/CMD never return, Node kernel times out; coding tasks blocked

What version of the Codex App are you using (From “About Codex” dialog)?

Unavailable from this session. Local execution is itself failing, and the About dialog has not been inspected. Please correlate the affected task with the installed build; no version is inferred from other reports.

What subscription do you have?

Not verified in this report.

What platform is your computer?

Codex desktop app on Windows, native local project, default shell PowerShell. Exact Windows build and architecture have not been retrieved.

Environment reported to the agent: workspace-write filesystem sandbox, restricted network, auto-review approvals. Workspace and user paths are omitted.

What issue are you seeing?

Requested severity: Critical — recurring failure of the core local coding workflow. Please escalate to the Codex Windows desktop / local execution runtime team for urgent triage and ownership.

The user reports this is a repeatedly recurring problem. This report contains direct evidence from one affected task on 10 September 2026 (Europe/Prague, UTC+02:00), with a further stalled local read during preparation of this report. The exact first-failure timestamp is unavailable; the incident was still under investigation at 19:18 UTC / 21:18 CEST.

The user asked the agent to update a local branch from remote develop before implementing an assigned engineering task. Local execution produced neither command output nor an exec session ID, preventing even the repository preflight. The branch update and implementation could not begin. Switching shells and trying the local Node runtime did not recover execution.

Remote Linear and GitHub connector requests returned successfully during the same incident, and the assistant continued responding. This is an observed difference between tool paths, not proof of a specific root cause.

What steps can reproduce the bug?

These are diagnostic probes in the already-failing session; the trigger that originally put the app into this state is unknown.

1. In a local Windows project task, invoke the agent's exec_command with a read-only repository-instruction/file search command. The enclosing functions.exec yields Script running with cell ID 1 after approximately 31 seconds. Repeated waits return no command result.

2. Reduce to PowerShell Get-Location, using login: false and yield_time_ms: 1000. The enclosing call again yields after approximately 31 seconds; subsequent waits return no output.

3. Try a different shell with this exact argument shape:

   {
     "cmd": "echo LOCAL_EXEC_OK",
     "shell": "C:\\Windows\\System32\\cmd.exe",
     "login": false,
     "yield_time_ms": 1000,
     "max_output_tokens": 1000
   }
   

   The enclosing call yields after approximately 31 seconds and remains pending. No LOCAL_EXEC_OK, exit code, or underlying exec session ID is returned.

4. Try the separate local mcp__node_repl__js tool with read-only node:fs/promises access. After 30.1 seconds it returns:

   js execution timed out; kernel reset, rerun your request
   

5. Reduce the Node probe to code that performs no file read, import, or child-process launch:

   nodeRepl.write({cwd:nodeRepl.cwd, runtime:'ok'});
   

   With timeout_ms: 10000, it returns the same kernel-reset error after 10.2 seconds.

6. During the same incident, read-only Linear issue/comment requests complete normally. GitHub connector reads also work while preparing this report.

The initial three pending orchestration cells were explicitly terminated after the probes. Those acknowledgements confirm termination of the orchestration cells only; no process-level cleanup result was available. A later read-only attempt to load local guidance during report preparation also remained pending.

Important distinction: functions.exec cell IDs are orchestration IDs, not exec_command process/session IDs. The approximately 31-second yield is not evidence that Windows created a child process, nor is yield_time_ms being treated as a hard command timeout.

What is the expected behavior?

• Trivial local commands and a no-I/O Node probe should return promptly.
• If local execution cannot initialize or dispatch, return a bounded, actionable error identifying the failing stage.
• Provide a supported way to recover the execution host without abandoning the task or repeatedly restarting the entire app.
• Cancellation should expose whether any child process was started and whether cleanup completed.
• The agent should be able to obtain sanitized diagnostics even when the normal command channel is unavailable.

Additional information

Impact: the affected coding task is completely blocked before branch synchronization, code changes, or tests. Repeated attempts consume time without producing useful work. The user explicitly requested Critical escalation because this keeps recurring.

What was tried: default shell, PowerShell with login disabled, explicit CMD with a built-in echo, separate local Node runtime, and a minimal no-I/O Node probe. Restarting the app was suggested, but no restart or successful recovery is evidenced in this session. No permissions, sandbox settings, or security configuration were changed.

What is not established: whether the failure is in tool dispatch, sandbox initialization, runtime startup, IPC, process creation, or result delivery. No app-wide freeze, memory exhaustion, security-review rejection, or root cause is claimed.

Requested escalation:

1. Assign an owner in Windows desktop/local runtime engineering and confirm triage priority.
2. Investigate why exec dispatch can remain pending without returning a session ID while the independent Node kernel also times out.
3. Add bounded initialization/dispatch watchdogs and stage-specific diagnostics, plus a supported recovery path.
4. Provide a secure diagnostic collection route that does not depend on the broken shell.

Potentially adjacent report: #41049 concerns a Windows code-mode host handshake failure. This session did not emit that handshake error, so equivalence is unconfirmed. A search of existing Windows/exec hang reports did not establish an exact duplicate.

This public report is deliberately limited to sanitized tool inputs/results. It omits private repository contents, internal issue details, account identifiers, credentials, and raw local logs. No formal in-app feedback ID has been generated.

Start with the functions.exec/exec_command path and the separate mcp__node_repl__js entry point, reproducing the PowerShell, CMD, and no-I/O Node probes described in the report. Trace whether the failure occurs during dispatch, sandbox initialization, runtime startup, IPC, process creation, or result delivery. Done means bounded stage-specific errors, observable cancellation and cleanup, a supported recovery path, and sanitized diagnostics when local execution is unavailable.