Windows Codex app: apply_patch hangs indefinitely while shell commands continue working

Open
#35,449 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
powershell, rust
Domain
desktop, operating-systems, tooling

Research direction

Reproduce the one-line .gitignore patch in the Windows Codex desktop app with a bounded timeout, then inspect %LOCALAPPDATA%\Codex\Logs and the generated apply_patch.bat wrapper. Start by comparing the reported Windows shell-environment timeout with the wrapper's behavior while ordinary PowerShell commands succeed. Done means apply_patch returns promptly and the target file is modified or an actionable error is reported.

Written by the indexing model from the issue text.

Description

app bug tool-calls windows-os
What version of the Codex App are you using (From “About Codex” dialog)?

26.721.4979.0

What subscription do you have?

Chat GPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The apply_patch tool hangs indefinitely and does not modify the target file. Ordinary read-only PowerShell commands continue to complete normally.

What steps can reproduce the bug?

  1. Open a local project in the Windows Codex desktop app.

  2. Request a one-line patch to .gitignore.

  3. Codex invokes apply_patch.

  4. The operation remains pending for more than 60–180 seconds.

  5. Interrupt the operation.

  6. Verify that the file was not changed.

What is the expected behavior?

Expected result:

The patch should apply promptly and return a success or actionable error.

Actual result:

The patch operation never returns and the file remains unchanged.

Troubleshooting already performed:

Fully restarted the Codex desktop app.

Fully restarted Windows.

Confirmed the project directory is readable and writable.

Confirmed ordinary PowerShell commands work.

Tested a one-line patch.

Tested direct invocation of the generated apply_patch.bat wrapper with a bounded timeout.

Reviewed Comodo Firewall/HIPS blocked items.

Unblocked the exact earlier wrapper for HIPS.

After the Windows restart, the newly generated wrapper did not appear in Comodo’s blocked list, but the patch still hung.

No real or confidential data was used.

Additional information

Codex logs previously recorded a timeout while loading the Windows shell environment. Comodo also appears to interact heavily with generated scripts, but the final post-reboot reproduction did not create a new blocked-wrapper event.

Relevant logs are available from:

%LOCALAPPDATA%\Codex\Logs

I can provide reviewed/redacted logs privately if requested.

Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.