codex - 💡(How to fix) Fix Codex Desktop on WSL: apply_patch always requests approval in writable workspace, while normal shell writes do not [4 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#18365Fetched 2026-04-18 05:55:11
View on GitHub
Comments
4
Participants
2
Timeline
12
Reactions
0
Author
Timeline (top)
labeled ×5commented ×4unlabeled ×2subscribed ×1

Fix Action

Fix / Workaround

  • apply_patch always triggers the approval flow, even for tiny writes in the current writable workspace like Playground, or in git-controlled repos. This did not happen before.
  • The session logs show those attempts ending as patch_apply_end with status:"declined" and stderr:"patch rejected by user".
  • Ordinary shell writes in the same workspace succeeded without approval. I created shell_write_probe.txt directly with touch, and that worked.

Ask the agent to edit a file within a Git-repo. It will attempt to use apply_patch and ask you for permissions, even though permissions are configured to allow edits. Other edit tools work fine.

apply_patch works without asking for permission.

RAW_BUFFERClick to expand / collapse

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

26.415.20818

What subscription do you have?

Pro $200

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

The issue began after the latest app update. It includes desktop runtime codex-cli 0.122.0-alpha.1

  • apply_patch always triggers the approval flow, even for tiny writes in the current writable workspace like Playground, or in git-controlled repos. This did not happen before.
  • The session logs show those attempts ending as patch_apply_end with status:"declined" and stderr:"patch rejected by user".
  • Ordinary shell writes in the same workspace succeeded without approval. I created shell_write_probe.txt directly with touch, and that worked.

What steps can reproduce the bug?

Uploaded thread: 019d9c61-6002-79a1-b36b-6459c0afa675

Ask the agent to edit a file within a Git-repo. It will attempt to use apply_patch and ask you for permissions, even though permissions are configured to allow edits. Other edit tools work fine.

What is the expected behavior?

apply_patch works without asking for permission.

Additional information

Here is my config.toml that is active. However switching to default permissions did not fix this problem either. Nor did changing the windows sandbox values.

#:schema https://developers.openai.com/codex/config-schema.json model = "gpt-5.4" model_reasoning_effort = "high" personality = "pragmatic"

full-auto mode

approval_policy = "on-request" sandbox_mode = "workspace-write"

file_opener = "vscode" plan_mode_reasoning_effort = "high"

[features] unified_exec = true shell_snapshot = true undo = true prevent_idle_sleep = true multi_agent = true

[shell_environment_policy] inherit = "all" ignore_default_excludes = true

Allow the agent to use the network when running in your workspace

[sandbox_workspace_write] network_access = true writable_roots = [ "/home/ekane/.m2", "/mnt/c/Users/eschu/.codex/skills/playwright-skill", "/home/ekane/src/github.com/sentrylink/webapp", "/home/ekane/src/github.com/sentrylink/terraform", "/home/ekane/src/github.com/sentrylink/sysadmin", "/tmp" ]

[tui] notifications = true status_line = ["model-with-reasoning", "current-dir", "git-branch"]

[history] persistence = "save-all" max_bytes = 104857600 # 100 MB

[projects."/home/ekane/src/github.com"] trust_level = "trusted"

[projects."/home/ekane/src/github.com/sentrylink/webapp"] trust_level = "trusted"

[projects."/home/ekane/src/github.com/sentrylink/batchjobs"] trust_level = "trusted"

[projects."/home/ekane/src/github.com/novalabs/NovaPassServer"] trust_level = "trusted"

[projects."/home/ekane/src/github.com/sentrylink/terraform"] trust_level = "trusted"

[projects."/home/ekane/src/github.com/sentrylink/sysadmin"] trust_level = "trusted"

[projects."/home/ekane"] trust_level = "trusted"

[projects."/mnt/c/Users/eschu/OneDrive/Documents/Playground"] trust_level = "trusted"

[plugins."google-calendar@openai-curated"] enabled = true

[plugins."gmail@openai-curated"] enabled = true

[plugins."github@openai-curated"] enabled = true

[plugins."google-drive@openai-curated"] enabled = true

[windows] sandbox = "unelevated"

extent analysis

TL;DR

The issue with apply_patch always triggering the approval flow, even for tiny writes in trusted workspaces, may be related to the recent update of the Codex App and the introduction of codex-cli 0.122.0-alpha.1, and can potentially be mitigated by adjusting the approval policy or trust levels in the config.toml file.

Guidance

  • Review the approval_policy setting in the config.toml file, currently set to "on-request", and consider adjusting it to a more permissive setting if the current behavior is not desired.
  • Verify that the workspaces where apply_patch is being used are correctly configured as trusted in the [projects] section of the config.toml file, as seen with the trust_level = "trusted" settings for various projects.
  • Check if the codex-cli 0.122.0-alpha.1 version introduces any changes to how patch applications are handled, potentially requiring updates to the configuration or workflow.
  • Test the behavior with different types of writes and workspaces to isolate if the issue is specific to certain conditions or configurations.

Example

No specific code snippet is provided as the issue seems to be related to configuration and workflow rather than code implementation.

Notes

The provided information suggests a potential issue with the configuration or the new version of codex-cli, but without more details on the changes introduced by codex-cli 0.122.0-alpha.1, it's challenging to provide a definitive solution. The steps provided are aimed at troubleshooting and potentially mitigating the issue through configuration adjustments.

Recommendation

Apply workaround: Adjust the approval_policy and verify trust levels for workspaces, as this seems to be the most direct approach to addressing the changed behavior of apply_patch without waiting for a potential fix in a future version of codex-cli.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING