Bug Report: `apply_patch` is inconsistently intercepted by Codex Desktop UI and `default_shell` configuration fails on Windows

Open 💬 2 comments Opened Mar 21, 2026 by Geekmemz

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

Codex 26.313.41514

What subscription do you have?

Team

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Environment

  • OS: Windows (Native)
  • App: Codex Desktop (UWP) / OpenAI.Codex
  • CLI Version: 0.115.0-alpha.27
  • Shell: Environment context shows <shell>powershell</shell> despite setting it to Git Bash.
  • Session ID(I had submitted a feedback in codex app):019d0e74-7acc-7990-81a2-e5ec0ccb9a84

Description

There are two distinct bugs related to how Codex Desktop handles shell execution and the apply_patch tool on Windows:

Bug 1: Unstable interception of apply_patch

When the AI attempts to use apply_patch via shell_command with bash heredoc syntax (e.g., apply_patch <<'PATCH'), the expected behavior is that the Codex engine intercepts this and handles the patch directly, showing a UI diff.
However, this interception is highly unstable.

  • Sometimes it works: The logs show Warning: apply_patch was requested via shell_command. Use the apply_patch tool instead of exec_command. and the UI correctly handles it.
  • Often it fails to intercept: The command is passed directly to the shell. Because the shell is PowerShell (see Bug 2), PowerShell fails to parse the bash heredoc syntax <<'PATCH', leading to syntax errors or pipeline timeouts, preventing the file from being edited.

Even when [apply_patch.bat](file:///C:/Users/Geekmemz/AppData/Roaming/npm/apply_patch.bat) is generated in .codex/tmp/arg0/, that directory is sometimes excluded from the sandbox PATH, meaning the command fails completely with The term 'apply_patch' is not recognized.

Bug 2: Custom Shell settings are ignored (Forced to PowerShell)

Despite configuring Codex to use Git Bash as the default terminal, the agent's environment_context consistently shows <shell>powershell</shell>. The [default.rules](file:///C:/Users/Geekmemz/.codex/rules/default.rules) are also hardcoded to use pwsh.exe. This forces the AI into a PowerShell environment where bash-specific syntax (which the AI frequently generates, like the heredoc apply_patch syntax) fails.

Steps to Reproduce

  1. Install Codex Desktop on Windows.
  2. In Codex settings, change the terminal type to Git Bash.
  3. Start a new session.
  4. Ask the AI to "create a test file using apply_patch".
  5. Observe the AI generating apply_patch <<'PATCH' syntax.
  6. Observe that sometimes it succeeds (intercepted), but often it falls back to the shell, which executes in PowerShell, resulting in syntax errors.

Expected Behavior

  1. The apply_patch interception should be 100% reliable so that it always triggers the UI diff viewer.
  2. If custom shells (like Git Bash) are selected in settings, the sandbox and environment_context should reflect this, allowing bash syntax to work if the interception fails.
  3. The arg0 directory containing [apply_patch.bat](file:///C:/Users/Geekmemz/AppData/Roaming/npm/apply_patch.bat) should consistently be added to the $env:PATH within the sandbox.

Workaround Attempted

We successfully created a PowerShell wrapper [apply_patch.ps1](file:///C:/Users/Geekmemz/AppData/Roaming/npm/apply_patch.ps1) in the global npm PATH that correctly parses PowerShell here-strings and passes them to codex.exe --codex-run-as-apply-patch. When instructed to use PowerShell syntax, this works perfectly. However, this is a command-line fallback and bypasses the native Codex Desktop UI diff viewer.

What steps can reproduce the bug?

Uploaded thread: 019d0e74-7acc-7990-81a2-e5ec0ccb9a84

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗