Windows Codex Desktop: internal apply_patch stalls indefinitely across projects while ordinary exec commands work

Open 💬 4 comments Opened Jul 19, 2026 by ShlomoShadmi
💡 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)?

Version 26.715.31925

What subscription do you have?

Business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

<img width="1053" height="2048" alt="Image" src="https://github.com/user-attachments/assets/b92409ca-3d55-4bf2-87c0-99255a1f7081" />

. Ordinary commands such as cmd.exe /d /c echo codex-ok work under Codex. The failure occurs across repositories and agents, particularly during substantive or UTF-8 edits. Agents then attempt PowerShell file-update fallbacks, which may also stall. Reinstalling, upgrading, and rebooting did not resolve it.

What steps can reproduce the bug?

This has occurred across multiple unrelated repositories and agents, so it does not appear to be repository-specific. It appears more frequently during substantive or UTF-8 file edits.

Control test inside Codex:

cmd.exe /d /c echo codex-ok

This completes successfully and returns codex-ok, showing that ordinary command execution works while the patch/editing path intermittently stalls.

Model observed: GPT-5.6-Sol Medium

What is the expected behavior?

This has occurred across multiple unrelated repositories and agents, so it does not appear to be repository-specific. It appears more frequently during substantive or UTF-8 file edits.

Control test inside Codex:

cmd.exe /d /c echo codex-ok

This completes successfully and returns codex-ok, showing that ordinary command execution works while the patch/editing path intermittently stalls.

Model observed: GPT-5.6-Sol Medium

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33719
  • #33877

Powered by Codex Action

ShlomoShadmi · 1 month ago

Troubleshooting already performed:

  • Reinstalled Codex Desktop last week.
  • Upgraded Codex Desktop to the latest available version today.
  • Rebooted Windows after upgrading.
  • Confirmed that PowerShell and cmd.exe work normally outside Codex.
  • Confirmed that a basic cmd.exe command also works inside Codex.
  • The behavior occurs across multiple projects and agents.
  • Changing repositories does not resolve it.
  • No normal permission prompt or actionable patch error is displayed.
  • where.exe apply_patch outside Codex returns no result, which is expected because the patch helper is supplied internally by Codex.

Screenshots showing the stalled task and successful command-control tests are attached.

ShlomoShadmi · 1 month ago

New reproduction after restarting Codex Desktop
The issue still occurs after restarting Codex Desktop.
The agent invoked the native apply_patch tool directly. It did not call apply_patch, apply_patch.bat, PowerShell, a heredoc, or any shell-based patch mechanism.
The test was deliberately minimal:
* Begin Patch
* Add File: .codex-patch-control.tmp
+patch-control
*** End Patch
Operation: create one file containing one line.
Patch size: five patch lines.

ShlomoShadmi · 1 month ago

New clean reproduction:

  • Invoked the dedicated native apply_patch tool directly.
  • Did not invoke apply_patch.bat, PowerShell, a heredoc, or any shell-writing fallback.
  • Used relative paths inside the current writable repository.
  • Test 1: add one small migration file. The tool remained pending for approximately one minute and had to be terminated.
  • Test 2: apply a single-line change to an existing repository file. The tool also remained pending and had to be terminated.
  • No success, validation failure, approval request, timeout result, or other actionable error was returned.

This rules out:

  • oversized patches;
  • absolute paths;
  • Windows command-line length limits;
  • PowerShell quoting;
  • heredoc parsing;
  • shell-wrapper invocation.

The behavior appears closer to #21117: the native apply_patch tool enters an unresolved sandbox/approval retry and never produces a tool result.