›_ Codex Issues
Codex Issues / #20874

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

Open 💬 7 comments Opened May 3, 2026 by albert-zen
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Observed from the running Windows process because the agent cannot open the About dialog directly:

  • Codex App package path: C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\Codex.exe
  • Codex App product version: 26.429.30905
  • Codex App file version: 2345
  • Bundled codex.exe product/file version: 0.128.0-alpha.1

What subscription do you have?

ChatGPT/Codex paid plan. The exact subscription string is not programmatically visible to the agent from this Windows session.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, shell commands run through the Codex App tool can complete but return empty stdout/stderr to the agent, and a PowerShell wrapper that redirects output can hang until the tool timeout even after the underlying command has already written the complete result.

This was observed while running an Elixir coverage gate from PowerShell in Codex App. The command itself generated the expected coverage report and exited, but the Codex App tool did not reliably surface the command output back to the conversation.

Observed cases:

  1. Direct failing coverage run:
mise exec -- mix test --cover

The Codex tool returned Exit code: 1 after about 59 seconds but with an empty output body. The useful coverage table was not visible in the tool result.

  1. Retried with explicit PowerShell log capture:
$log = Join-Path $env:TEMP ('symphony-cover-' + [guid]::NewGuid().ToString() + '.log')
mise exec -- mix test --cover *> $log
$exit = $LASTEXITCODE
Write-Output "EXIT=$exit"
Write-Output "LOG=$log"
Get-Content -Path $log -Tail 120
exit $exit

The Codex tool timed out after about 304 seconds. However, inspecting the generated temp log showed the coverage command had already completed and written its useful result after about 65 seconds:

Finished in 64.8 seconds (3.8s async, 61.0s sync)
547 tests, 0 failures, 7 skipped (9 excluded)

Coverage test failed, threshold not met:

    Coverage:   94.51%
    Threshold:  95.00%
  1. Direct successful coverage run after adding tests:
mise exec -- mix test --cover

The Codex tool returned Exit code: 0 after about 58 seconds, again with an empty output body.

The issue is not that full coverage is slow; the test suite duration is expected. The problem is that Codex App sometimes fails to deliver stdout/stderr from a completed Windows command, and in the redirected wrapper case the tool did not return promptly after the useful output had already been written.

What steps can reproduce the bug?

A public reproduction candidate is the Windows-native Symphony repository:

git clone https://github.com/albert-zen/symphony-windows-native.git
cd symphony-windows-native\elixir
mise trust
mise install
mise exec -- mix deps.get
mise exec -- mix test --cover

In the affected Codex App session on Windows, the command completed but the Codex tool response body was empty. A wrapper that redirects output to a temp log and then tails the log may hang until the tool timeout even though the log already contains the completed coverage result.

The behavior was observed from a PowerShell shell in Codex App with:

  • Windows: Microsoft Windows NT 10.0.26200.0 x64
  • Codex App package: OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0
  • Bundled CLI: 0.128.0-alpha.1
  • Command launched via the Codex shell tool from workspace D:\desktop\symphony\elixir

No secrets are required to reproduce this particular output-capture behavior.

What is the expected behavior?

When a Windows command completes, Codex App should reliably return the captured stdout/stderr to the conversation, including for non-zero exits.

For a PowerShell wrapper that redirects output and then prints a tail, Codex App should return promptly once the wrapper exits and should not continue waiting until the tool timeout after the underlying command has already completed and the log has already been written.

At minimum, the tool result should include enough output to diagnose the failure without rerunning the same broad gate.

Additional information

This caused unnecessary repeated full coverage runs during a coding session because the first failing run already had enough information, but Codex App did not surface it. The local workaround is to avoid rerunning the broad gate and inspect generated files/logs directly, but the app-level behavior makes Windows debugging and validation loops more expensive than needed.

I searched for nearby existing issues with terms like Windows PowerShell stdout mix test cover Codex App, tool output empty Windows command timeout, and mise exec PowerShell output, and did not find an obvious duplicate.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 2 months ago

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

  • #19692
  • #20807

Powered by Codex Action

Shadetail · 1 month ago

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.

bosschen0429 · 6 days ago

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.

leskei217 · 6 days ago

+1
Windows 11 app
Version 26.707.72221

bosschen0429 · 5 days ago

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.

zach-jaggars · 4 days ago

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.

ricardosalta · 3 days ago

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.