Codex App on Windows sometimes drops completed command output and can hang after redirected output is written

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

• #19692
• #20807

Powered by Codex Action

We're seeing what looks like the same bug on the codex exec CLI path (not the desktop App), which suggests the fault is in shared Windows shell-execution code rather than App-specific glue. Posting a minimal, fully non-interactive repro in case it helps narrow it down.

Environment

• Windows 11
• codex-cli 0.133.0 (also observed on earlier 0.12x)
• Invocation: codex exec --json --dangerously-bypass-approvals-and-sandbox -m <model> -, driven programmatically from a parent process that writes the prompt to stdin and then closes it (so this is not #20919 — stdin gets a clean EOF)
• No sandbox (full access); shell is PowerShell

Symptom

A short, read-only shell command that completes in well under a second when run by hand is emitted as item.started with status:"in_progress" / exit_code:null and then never receives an item.completed. Codex stops streaming entirely — no stderr, no tools::router error, only a few hundred bytes of stdout. The outer process just sits there (0% CPU) until our own watchdog kills it at a stdout-silence timeout.

This is not the large-output back-pressure deadlock from #18983 (that one is fixed and we're well past it): here total captured stdout is ~700 bytes and there is no nonzero exit involved at all.

Strong correlation: it happens when codex launches multiple commands concurrently

Across every captured instance, the hung sessions had 2–10 commands in_progress at once. The cleanest example is two parallel read-only VCS metadata commands (Perforce p4 describe) started in the same turn:

{"type":"thread.started","thread_id":"…"}
{"type":"turn.started"}
{"type":"item.completed","item":{"id":"item_0","type":"agent_message","text":"…"}}
{"type":"item.started","item":{"id":"item_1","type":"command_execution","command":"powershell.exe -Command 'p4 describe -du <CL>'","status":"in_progress","exit_code":null}}
{"type":"item.started","item":{"id":"item_2","type":"command_execution","command":"powershell.exe -Command 'p4 describe -s <CL>'","status":"in_progress","exit_code":null}}
   // ← stream ends here. Both commands complete in <1s when run manually.
   //   No item.completed for either. No stderr. ~700 bytes total stdout.

Deterministic on an affected input

We retried the same prompt 4× and got an identical hang every time — each run ~110s (process startup + our 90s stdout-silence watchdog), tiny stdout, same two commands stuck in_progress. So for some inputs it reproduces every time, not just intermittently.

This matches the issue description ("a completed Windows command's output isn't surfaced; the tool hangs until timeout"), but on the pure exec CLI path and with a much simpler trigger than a long coverage run — just fast read-only commands issued in parallel. If the completion/output is being dropped on a per-PTY or per-channel basis when several commands run concurrently, the "multiple in-flight commands" angle might be where to look.

Happy to share full (sanitized) --json transcripts if useful.

I can reproduce a much smaller related failure on Windows Codex Desktop.

Observed on 2026-07-14.

Minimal A/B reproduction

Through Codex App

Execution surface: Git Bash MCP

Command:

head -n 5 -- /c/tmp/codex-ux-benchmark/README.md

Configured timeout: 5000 ms

Observed result:

• No stdout or stderr.
• The call was still running after more than 10 seconds.
• The configured timeout was not delivered back to the agent.
• I had to terminate the outer execution manually.

Outside Codex

From a normal PowerShell terminal, with Codex not acting as the parent:

Get-Content -LiteralPath 'C:\tmp\codex-ux-benchmark\README.md' -TotalCount 5

This returned the expected content immediately.

Reproducibility

The problem persisted after:

• opening a fresh Codex task;
• completely exiting and restarting Codex Desktop;
• using a neutral file under C:\tmp;
• changing from PowerShell to native rg and Git Bash MCP;
• attempting an escalated read.

Additional observations:

• A PowerShell Get-Content call with a 20-second timeout remained silent for more than 30 seconds.
• A single-file native rg call with a 5-second timeout remained silent for more than 10 seconds.
• A Node REPL MCP read of a small file returned its own timeout and reset after about 5.6 seconds, so timeout behavior differs between tool surfaces.
• No files were modified during these tests.

Expected behavior

Either:

1. the small file read should return immediately; or
2. the configured timeout should terminate/cancel the command and return a structured timeout result within the requested deadline.

The Codex App should not remain indefinitely in a running state after the tool deadline.

Scope of the evidence

The fast out-of-band PowerShell control rules out the file contents, ordinary PowerShell behavior, and a general inability of Windows to read the file.

This does not yet identify whether the failure is in command orchestration, sandbox/broker execution, process cleanup, stdout/stderr delivery, or an endpoint filter applied specifically to Codex-spawned processes. PID and lifecycle-stage telemetry were not available.

Codex App and Windows build versions were not queried through the affected execution surface because further local process execution had been quarantined.

+1
Windows 11 app
Version 26.707.72221

Follow-up to my 2026-07-14 minimal A/B report, with a smaller and more discriminating reproduction observed on 2026-07-15.

Environment

• Windows 11
• Codex Desktop package: 26.707.3563.0
• Bundled/local command runner: codex-command-runner-0.144.0-alpha.4.exe
• The packaged and locally staged helper binaries are present and byte-identical:
• codex-command-runner.exe: SHA256 01A582479BF7D31E3EF3F2CBA5BB22DBA5A1D5542CE850B44BBE0217BB4A327E
• codex-windows-sandbox-setup.exe: SHA256 5FBFC00734EBB13DC6E0D0323ABE130AD75A979F59A3B84299BDD48A67844FB2

This rules out a missing helper or a stale/incomplete local helper copy in this instance.

New minimal reproduction

1. Single command through Codex Desktop

The agent invoked only:

Write-Output 'CODEX_EXEC_OK'

Conditions:

• login: false
• tested from both the repository and C:\tmp
• configured timeout: 5 seconds
• no filesystem input and negligible stdout

Observed:

• no stdout or stderr
• remained running beyond 10 seconds
• configured timeout was not returned
• outer execution had to be terminated manually

2. Side-effect canary distinguishes this from output-only loss

The agent attempted an apply_patch that would only add a uniquely named disposable file containing one line.

Observed:

• patch call remained running beyond 10 seconds
• after terminating the outer call, an out-of-band PowerShell Test-Path returned EXISTS=false

Therefore this occurrence is not only "the command completed but stdout/stderr was dropped": the requested side effect was never applied.

3. Direct bundled CLI also hangs

From normal out-of-band PowerShell:

& 'C:\Users\user\AppData\Local\OpenAI\Codex\bin\a7c12ebff69fb123\codex.exe' sandbox windows --permissions-profile ':read-only' --cd $env:TEMP -- "$env:WINDIR\System32\whoami.exe"

Observed:

• no response after more than 60 seconds
• required Ctrl+C

This suggests the current failure is not confined to Desktop conversation output rendering.

Lifecycle observations

• A runner process appeared under %USERPROFILE%\.codex\.sandbox-bin.
• Terminating that runner and retrying the single fixed-output canary did not recover execution.
• Switching to the unelevated Windows sandbox workaround did not restore execution.
• %USERPROFILE%\.codex\.sandbox\setup_error.json does not exist.
• %USERPROFILE%\.codex\.sandbox\sandbox.log does not exist.
• Permission prompts and non-process Codex App APIs still respond normally.

The absence of both the setup error artifact and sandbox log makes it look as though the hang occurs before normal Windows sandbox lifecycle logging, or on a path that does not emit those artifacts.

Impact / request

In this state, all normal local work is blocked: read-only shell commands, apply_patch, and the direct bundled sandbox command. Retrying, changing cwd/shell, opening a fresh task, fully restarting Desktop, escalation, stopping the runner, and switching to unelevated sandbox have not recovered it.

Please add a hard watchdog and structured lifecycle-stage error around helper/runner startup so a five-second tool deadline cannot remain indefinitely in_progress. Logging before sandbox setup/runner launch would also make it possible to distinguish command orchestration, broker launch, ACL setup, endpoint filtering, and completion delivery failures without repeated blind retries.

I can reproduce a broader version of this in the Codex Desktop app on native Windows.

Minimal repro in a fresh task, local workspace:

Write-Output "shell-probe-ok"

Expected: immediate stdout and exit.
Actual: the shell_command tool produces no output and remains running; I terminated it after ~10 seconds.

Additional observations:

• Reproduces across PowerShell and cmd.exe, in multiple working directories, including with and without sandbox escalation.
• Restarting Codex Desktop and rebooting Windows did not resolve it.
• Codex reported: No app terminal session is attached to this thread yet.
• The local Node runner also timed out on a literal nodeRepl.write("node-probe-ok") call, while in-process Codex Desktop dependency discovery still worked.

This suggests the command/kernel result-return or terminal-session path may be failing, not the command itself. Happy to provide Codex Desktop version, Windows build, or any diagnostics that would help.

Additional Windows data point with a workaround that resolved the problem for my setup.

Environment:

• Codex Desktop 26.707.31428
• Older Windows machine under heavy system load
• Other applications remained responsive during the tests

Observed behavior:

• Get-Date -Format o did not return normally through the shell tool. Its output appeared when the 45-second timeout fired.
• cmd.exe /d /c "echo shell-ok" showed the same behavior with a 10-second timeout, so this was not specific to a PowerShell cmdlet.
• Running with login=false returned Get-Date in approximately three seconds.

I then set the following in %USERPROFILE%\.codex\config.toml:

allow_login_shell = false

Subsequent shell commands returned normally in the same Codex session. I did not restart Codex.

For my use case, this resolved the practical problem. My Codex commands do not depend on profile-defined aliases, functions, or environment initialization.

I have only noticed the failure while the machine is under heavy load. That is an observed correlation, not proof that load is the root cause.

This does not establish allow_login_shell = false as a universal fix, but it appears to be a reliable workaround when profile initialization is unnecessary.

Additional reproducible observation from Codex Desktop on Windows (2026-07-22).

This is happening repeatedly during a long-running coding task, and each stall requires manual user intervention (sending another message or restarting/resuming the app) before useful work continues. The UI can keep presenting the agent as busy even though no implementation or rendering work is progressing. That defeats the expectation that an autonomous task can continue without the user repeatedly checking and unblocking it.

Most recent minimal case:

Get-Content -Raw -Encoding utf8 '<small-markdown-file>' | Out-Null
Get-Date -Format 'yyyy-MM-dd HH:mm zzz'

Observed behavior:

• The Markdown file was only about 6 KB.
• The command intentionally discarded the file contents, so expected stdout was only one short date line.
• The shell call had a 10-second timeout, but the surrounding tool execution remained occupied for about 60 seconds and returned Script running with cell ID ....
• A subsequent attempt to terminate/resume that cell reported that the cell could no longer be found.
• After the user intervened, reading the same files through bounded Node filesystem I/O completed in roughly 0.3 seconds. The file and disk access were therefore not the bottleneck.

This looks related to this issue, but it extends the reproduction beyond long-running commands or large/rapid output. A tiny file plus a PowerShell pipeline to Out-Null was enough to wedge the shell/tool lifecycle.

This has occurred multiple times in the same task: Codex becomes silent or appears busy without forward progress, and the user must manually interrupt or prompt it again. That should not be necessary.

Expected behavior:

1. The requested timeout is honored.
2. The tool returns a terminal result and stable stdout/stderr.
3. The agent loop resumes automatically after a timeout/failure.
4. Cell/process lifecycle remains addressable until cleanup is confirmed.
5. No user intervention is required to make the task continue.

Possibly related: #18983, although that report focused on very large Get-Content -Raw output and is now closed. This reproduction involved very small input and effectively no streamed file output.

Additional current-version data point from Windows with codex-cli 0.146.0:

• A nested codex exec --json launched through the Codex App shell_command transport appeared completely silent to the parent for more than 12 minutes.
• The retained rollout contained 275 records with continuous reasoning and completed tool calls during that interval, so the executor was active.
• In a bounded explicit-executable probe, the same CLI wrote thread.started and turn.started to an independently redirected stdout file within 15 seconds while the process was still running.

This rules out CLI-side buffering-until-exit for this reproduction and points to the parent/App transport not forwarding incremental child stdout. An unavailable optional HTTP MCP endpoint added startup retries, but the early JSONL events existed before completion and were still not visible through the parent transport.

I can reproduce this consistently on Windows, and I was able to narrow down the trigger.

Environment:

- Codex Desktop: 26.803.5235.0
- Bundled Codex CLI: 0.147.0-alpha.6.5
- OS: Microsoft Windows NT 10.0.22621.0
- PowerShell: 7.6.3 Core

The problematic combination is:

- `Start-Process`
- `-RedirectStandardOutput` and/or `-RedirectStandardError`
- a long-running child process

Minimal reproduction:

```powershell
$o = Join-Path $env:TEMP 'codex-repro.stdout.log'
$e = Join-Path $env:TEMP 'codex-repro.stderr.log'

Write-Output ('before=' + (Get-Date -Format o))

Start-Process `
  -FilePath 'ping.exe' `
  -ArgumentList '127.0.0.1','-n','3' `
  -WindowStyle Hidden `
  -RedirectStandardOutput $o `
  -RedirectStandardError $e

Write-Output ('after=' + (Get-Date -Format o))

Run the command through shell_command with:

{"timeout_ms": 1500}

Observed result:

before=2026-08-09T10:44:04.8634792+08:00
after=2026-08-09T10:44:04.9506183+08:00
Wall time: 3.2 seconds
Exit code: 0

The PowerShell statements themselves completed about 87 ms apart, but the Codex command did not return until the child process exited. The configured 1500 ms timeout was not enforced.

Control experiment:

Start-Process `
  -FilePath 'ping.exe' `
  -ArgumentList '127.0.0.1','-n','4' `
  -WindowStyle Hidden

Write-Output 'parent-returned-no-redirect'

Without -RedirectStandardOutput/-RedirectStandardError, Codex returned in approximately 1.3 seconds while the child process continued running.

The real-world failure involved launching Flask:

Start-Process `
  -FilePath 'python' `
  -ArgumentList '-u','flask_app.py' `
  -WindowStyle Hidden `
  -RedirectStandardOutput $stdout `
  -RedirectStandardError $stderr

The shell_command call had timeout_ms: 3000, but it remained unresolved for more than 14 minutes until the turn was manually interrupted. During that time, the Flask health endpoint was already returning HTTP 200, confirming that the service had started successfully and only the command completion channel was stuck.

A working workaround is to ensure that the outer Start-Process has no redirected streams. Redirection can instead be performed inside an already detached child shell:

$childScript = @"
& python -u flask_app.py 1>> '$stdout' 2>> '$stderr'
"@

$encoded = [Convert]::ToBase64String(
    [Text.Encoding]::Unicode.GetBytes($childScript)
)

Start-Process `
  -FilePath 'pwsh.exe' `
  -ArgumentList '-NoProfile','-EncodedCommand',$encoded `
  -WindowStyle Hidden

This form returns promptly while the detached child continues writing its logs.

It appears that either the PowerShell host teardown or Codex's Windows unified-exec process/pipe tracking keeps the command open until the redirected child closes its handles. In addition, timeout_ms is not reliably enforced on this path.

Expected behavior:

1. A detached Start-Process child should not keep the parent shell_command unresolved.
2. At minimum, timeout_ms should return control when its deadline is reached.
3. Ideally Codex should provide an explicit background/detached process mode on Windows.