›_ Codex Issues
Codex Issues / #18365

Codex Desktop on WSL: apply_patch always requests approval in writable workspace, while normal shell writes do not

Resolved 💬 11 comments Opened Apr 17, 2026 by eschulma Closed Apr 20, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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"

View original on GitHub ↗

11 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #17983
  • #18079

Powered by Codex Action

eschulma · 3 months ago

I believe this relates to https://github.com/openai/codex/issues/18069 . I was forced to revert to version 0.120.0 on WSL to even get this to work properly in the CLI. Since the app uses a higher version, the problem shows up there as well.

eschulma · 3 months ago

Although #18069 has resolved the issue in the CLI now via the codex-cli 0.122.0-alpha.9 release, the Windows app is still on 122-alpha.1 and so not usable for me or other WSL users. Guess I'm back to the CLI. Hopefully we get a Windows app update soon...

eschulma · 3 months ago

Still failing with the same issue in version 26.415.30602

eschulma · 3 months ago

Still failing with the same issue in version 26.415.40636. Well at least the app is getting regular updates...

yarsawyer · 3 months ago

The real edit path for apply_patch is not “agent writes file directly”. It is:

  1. agent calls apply_patch
  2. Codex spawns an internal fs-helper process
  3. that helper is sandboxed again
  4. helper performs the actual file mutation

The bug was in how Codex prepared that helper sandbox.

The core fix

In codex/codex-rs/exec-server/src/fs_sandbox.rs:45, the helper sandbox policy is built from the outer workspace-write policy before the helper is launched.

Old behavior:

  • helper inherited the outer network_access = true
  • but Codex separately forced the helper’s split network_policy to Restricted
  • so the helper was being launched with a policy pair that did not actually agree

That mismatch sat right here:

  • helper policy creation: codex/codex-rs/exec-server/src/fs_sandbox.rs:45
  • helper sandbox exec transform: codex/codex-rs/exec-server/src/fs_sandbox.rs:67

I changed codex/codex-rs/exec-server/src/fs_sandbox.rs:264 so the helper policy is normalized to what the helper actually needs:

  • enable platform defaults for read access
  • force network_access = false for helper sandboxes

That matters because the fs-helper does not need network. Once the helper policy says “no network” and the split policy also says “restricted network”, the policy set becomes internally consistent.

So the pure-bwrap fix was:

  • before: helper legacy-style policy said network allowed, split policy said network restricted
  • after: both say restricted/no-network, so SandboxManager can build the helper sandbox cleanly and launch it under bwrap

The second fix

In codex/codex-rs/exec-server/src/fs_sandbox.rs:114, I also made the extra helper executable read-root conditional on legacy mode.

  • under pure bwrap, Codex can still add the helper binary directory as a read root
  • under legacy Landlock, it now skips that injection

That part was mainly to stop legacy mode from producing a filesystem policy Landlock could not represent. It is not the reason pure bwrap works now, but it removed the other half of the failure you
were hitting earlier.

Why it now works without legacy Landlock

With your current config:

  • use_legacy_landlock = false
  • fresh session
  • no warning

Codex is taking the pure bwrap branch in codex/codex-rs/linux-sandbox/src/linux_run_main.rs:177.

That path was already structurally fine. What was broken was the helper policy being handed into it. After the helper-policy normalization fix, the helper child can be sandboxed and started
correctly, so apply_patch completes instead of dying and triggering the approval fallback.

What the Linux fallback patch did

The changes in codex/codex-rs/linux-sandbox/src/linux_run_main.rs:404 added a real fallback when bwrap setup genuinely fails. That is a robustness fix.

It is not the code path your working restarted session is using now.

Your current successful path is:

  • pure bwrap
  • helper policy normalized correctly
  • fs-helper launches
  • patch applies

So the precise answer is:

  • I did not “make Ubuntu bwrap work”
  • I fixed Codex so its internal helper sandbox policy stopped conflicting with the pure-bwrap execution model
  • and I added a proper fallback path for real bwrap setup failures as a separate guardrail

That is why, after removing legacy Landlock and restarting, apply_patch now works directly.

eschulma · 3 months ago

@yarsawyer are you a contributor to this repo or are you describing a fork?

I did quite a few experiments. Once Open AI updates the underlying codex CLI the desktop app calls within WSL to version 0.122.0-alpha.9 or higher it should fix this issue. Presumably (hopefully) this will happen when version 0.123 stable is out.

yarsawyer · 3 months ago
@yarsawyer are you a contributor to this repo or are you describing a fork? I did quite a few experiments. Once Open AI updates the underlying codex CLI the desktop app calls within WSL to version 0.122.0-alpha.9 or higher it should fix this issue. Presumably (hopefully) this will happen when version 0.123 stable is out.

i am describing what has helped me to fix the problem.

eschulma · 3 months ago
> @yarsawyer are you a contributor to this repo or are you describing a fork? > I did quite a few experiments. Once Open AI updates the underlying codex CLI the desktop app calls within WSL to version 0.122.0-alpha.9 or higher it should fix this issue. Presumably (hopefully) this will happen when version 0.123 stable is out. i am describing what has helped me to fix the problem.

Thank you very much. I guess I will wait a few days for Open AI to fix this as I don't really want to fork such an active repo. I was at least happy to get the CLI working again with 0.122.0-alpha.9, I can live without the app for a while.

jesse-black · 3 months ago

I'm experiencing this too since version 26.415.20818 and still happening on pre-release version 26.5415.20818

Using Codex VS Code extension on windows with ssh remote to debian based devcontainer image

apply_patch always requests approval even after selecting "yes, and don't ask again this session"

eschulma · 3 months ago

The app has updated to codex-cli 0.122.0-alpha.13 and as predicted, that fixed the issue.