Windows Desktop 26.803.10989.0: apply_patch hangs indefinitely while shell I/O works
What version of the Codex App are you using (From “About Codex” dialog)?
26.803.10989.0
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
On Codex Desktop for Windows, every apply_patch call hangs indefinitely before applying any filesystem change. This reproduces with a one-line disposable file as well as small updates to existing files.
Normal shell commands can read the workspace immediately, and the workspace is configured writable. The Windows sandbox setup log reports successful setup with errors=[]. No patch attempt appears to reach the sandbox command-runner log.
The behavior persisted after:
- fully terminating all
codex*processes - restarting the official Codex app
- checking Microsoft Store for updates
- disabling Comodo Auto-Containment and trusting the Codex executables
- testing a minimal file in the workspace root
The tool remains in a running state until manually terminated. No target file is created or modified.
This appears similar to openai/codex#34549, openai/codex#34290, openai/codex#13965/openai/codex#13959, and openai/codex#29365, but it still reproduces on app version 26.803.10989.0 with command runner 0.147.0-alpha.6.6.
What steps can reproduce the bug?
- Open the official Microsoft Store Codex Desktop app on Windows.
- Open a writable workspace.
- Invoke a minimal patch:
*** Begin Patch
*** Add File: .codex-patch-test.txt
+patch service test
*** End Patch
- Observe that the tool remains running indefinitely.
- Terminate the tool after 20-40 seconds.
- Verify that
.codex-patch-test.txtwas not created. - Run
Test-Path .codex-patch-test.txtor normal read commands; shell execution completes normally.
Session ID: 019ff59c-6f61-75a3-8d7f-5aa18d26be9f
What is the expected behavior?
A valid one-line patch in a writable workspace should complete within a few seconds, create the file, and return a clear success result. If a helper cannot launch, the tool should fail promptly with the underlying Windows error instead of hanging.
Additional information
Installed package: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
Observed processes:
codex.execodex-code-mode-host.execodex-command-runner-0.147.0-alpha.6.6.exe
The sandbox log shows setup refreshes completing successfully and the command runner being copied/reused from the packaged app. Ordinary shell access to the workspace succeeds. This strongly suggests the hang occurs in the app/tool bridge before the patch reaches filesystem execution.
No WindowsApps ownership or ACL changes were made.
3 Comments
I opened #38425 with a narrower launcher-path/control comparison that may explain one Windows-specific form of this hang.
In the same Codex Desktop version, the App-generated
apply_patch.battargets:C:\Program Files\WindowsApps\OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0\app\resources\codex.exe --codex-run-as-apply-patchThe integrated patch operation can remain non-returning, while invoking the same
--codex-run-as-apply-patchinterface through the standalone Codex CLI succeeds on the same bounded patch.That does not establish that every #38190 reproduction has the same cause, but it provides a controlled AppX-versus-standalone comparison. Full paths, hashes, and reproduction details are in #38425.
This appears to match my issue exactly 39690
Still reproduces after updating the desktop app on Aug. 20, 2026