Windows Desktop 26.803.10989.0: apply_patch hangs indefinitely while shell I/O works

Open 💬 3 comments Opened Aug 12, 2026 by shaynec777

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?

  1. Open the official Microsoft Store Codex Desktop app on Windows.
  2. Open a writable workspace.
  3. Invoke a minimal patch:
*** Begin Patch
*** Add File: .codex-patch-test.txt
+patch service test
*** End Patch
  1. Observe that the tool remains running indefinitely.
  2. Terminate the tool after 20-40 seconds.
  3. Verify that .codex-patch-test.txt was not created.
  4. Run Test-Path .codex-patch-test.txt or 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.exe
  • codex-code-mode-host.exe
  • codex-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.

View original on GitHub ↗

3 Comments

specimba · 14 days ago

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.bat targets:

C:\Program Files\WindowsApps\OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0\app\resources\codex.exe --codex-run-as-apply-patch

The integrated patch operation can remain non-returning, while invoking the same --codex-run-as-apply-patch interface 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.

RodgerDJr · 8 days ago

This appears to match my issue exactly 39690

RodgerDJr · 7 days ago

Still reproduces after updating the desktop app on Aug. 20, 2026