apply_patch edit attempts trigger misleading "command failed; retry without sandbox?" prompt even when bwrap and filesystem writes work

[juhyeonLGE]

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.17.0-1010-aws x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

tmux (TERM=tmux-256color, TERM_PROGRAM=tmux) over SSH on Linux

What issue are you seeing?

Codex repeatedly shows this prompt during normal edit attempts:

Would you like to make the following edits?

Reason: command failed; retry without sandbox?

This happens during simple file creation/edit operations that should be valid under workspace-write sandboxing.

Example repro:

1. Start Codex inside a writable worktree:
   cd /home/juhyeon2.kim/workspace/FinDy__prm-parser-docs-juhyeon2
   codex

2. Ask Codex to create a simple file, e.g.:
   "Create a file named codex-workspace-write-test and write a single line into it."

3. Codex reports an edit such as:
   Added codex-workspace-write-test (+1 -0)

4. Then the TUI immediately shows:
   Would you like to make the following edits?
   Reason: command failed; retry without sandbox?

Important context:

• The target directory is writable by my user.
• Manual shell writes in the same directory succeed.
• The Linux sandbox itself appears healthy now:
  • bwrap --ro-bind / / -- /bin/true -> OK
  • bwrap --unshare-net --ro-bind / / -- /bin/true -> OK
• This also reproduces when Codex is started directly inside the target worktree, not only from a parent directory.

What makes this confusing is that this prompt seems to appear for multiple failure classes, not just real sandbox denials. In earlier debugging I also saw the same prompt associated with:

• missing-file / bad-path errors
• skill/prompt routing mistakes
• verification commands failing for unrelated reasons

For the latest minimal repro, the behavior looks like this:

• Codex generates an apply_patch-style add-file edit
• the UI prompts "command failed; retry without sandbox?"
• if I do not approve the retry path, the file is not created
• the session logs show apply_patch was invoked, but the file does not actually exist afterward

This makes me suspect the issue is not necessarily a real current sandbox denial, but possibly:

• apply_patch / edit application failing internally, or
• the TUI classifying non-sandbox failures as sandbox retry prompts.

Additional debugging notes:

I previously had a real host-level Linux sandbox problem involving bubblewrap/AppArmor/user namespaces, but that was fixed separately. After the fix:

• bwrap works
• shell writes work
• this Codex edit prompt still occurs

So the current issue appears distinct from the earlier host sandbox problem.

Relevant local artifacts:

• ~/.codex/log/codex-tui.log
• ~/.codex/sessions/2026/04/16/rollout-2026-04-16T05-27-13-019d94c1-f72f-7e03-bc31-56e06530758d.jsonl
• ~/.codex/sessions/2026/04/16/rollout-2026-04-16T05-37-39-019d94cb-87bb-7353-abca-f0cad0ffa5e6.jsonl

What steps can reproduce the bug?

Reproduction steps

1. Start Codex CLI in a writable Linux worktree:

   cd /home/juhyeon2.kim/workspace/FinDy__prm-parser-docs-juhyeon2
   codex
   

2. Ask Codex to create a simple file in the current working directory, for example:

   Create a file named codex-workspace-write-test and write a single line into it.

3. Codex generates an edit plan and shows something like:

   Added codex-workspace-write-test (+1 -0)

4. Instead of applying the edit cleanly, the TUI shows:

   Would you like to make the following edits?

   Reason: command failed; retry without sandbox?

5. If I do not approve the fallback/retry path, the file is not created.

Notes

• This reproduces even when I launch Codex directly inside the target worktree.
• It also reproduced when launching from a parent workspace and targeting the same worktree below it.
• The issue is specifically confusing because the prompt looks like a sandbox denial, but the underlying cause does not appear to be a real current filesystem permission problem.

Example prompt used

Create a file named codex-workspace-write-test and write a single line into it.

Relevant thread/session ids

Recent sessions where I reproduced this:

• 019d94c1-f72f-7e03-bc31-56e06530758d
• 019d94cb-87bb-7353-abca-f0cad0ffa5e6

Relevant session files:

• ~/.codex/sessions/2026/04/16/rollout-2026-04-16T05-27-13-019d94c1-f72f-7e03-bc31-56e06530758d.jsonl
• ~/.codex/sessions/2026/04/16/rollout-2026-04-16T05-37-39-019d94cb-87bb-7353-abca-f0cad0ffa5e6.jsonl

What is the expected behavior?

Codex should either:

1. apply the edit successfully, because the target directory is writable and the sandbox is healthy, or
2. show the actual underlying failure if the edit cannot be applied.

It should not show the generic prompt:

Reason: command failed; retry without sandbox?

when the real issue does not appear to be an active sandbox denial.

In my environment:

• the target directory is writable by my user
• manual shell writes succeed in the same directory
• bwrap --ro-bind / / -- /bin/true succeeds
• bwrap --unshare-net --ro-bind / / -- /bin/true succeeds

So the expected behavior is that a normal add-file edit in the current worktree should complete without requiring a misleading sandbox retry prompt.

Additional information

I want to highlight that I initially did have a real host-level Linux sandbox problem involving bubblewrap, AppArmor, and unprivileged user namespaces. That issue was debugged and fixed
separately.

After that fix:

• bwrap basic sandboxing works
• bwrap --unshare-net works
• manual shell writes work
• this edit prompt still occurs

So the current issue appears to be separate from the earlier host-level sandbox failure.

I also observed that this same TUI prompt seems to appear for multiple failure classes, not only real sandbox denials. During broader debugging I saw it in situations involving:

• missing-file / bad-path errors
• skill/prompt routing mistakes
• verification command failures
• stale execution state from resumed sessions

That makes me suspect the TUI may be overloading the same "retry without sandbox" message for different underlying failure modes.

I also checked the latest repros and found:

• apply_patch was invoked in the session logs
• the target file still did not exist afterward
• the session ended with aborted by user after ...s
• I could not find a corresponding concrete shell failure that clearly explained the sandbox retry prompt in the latest minimal repro

So this may be an apply_patch / edit-application issue, or an error-classification issue in the TUI, rather than a real current sandbox denial.

Additional useful local artifacts:

• ~/.codex/log/codex-tui.log
• ~/.codex/sessions/2026/04/16/rollout-2026-04-16T05-27-13-019d94c1-f72f-7e03-bc31-56e06530758d.jsonl
• ~/.codex/sessions/2026/04/16/rollout-2026-04-16T05-37-39-019d94cb-87bb-7353-abca-f0cad0ffa5e6.jsonl

Potentially related issues:

• all commands in sandbox mode fail and need approval #3140
• codex --sandbox workspace-write --ask-for-approval never cannot write files #5824
• Sandbox mode forced as read only #5202
• Sandbox mode always set to readonly even if set to workspace_write in config.toml #6667
• apply_patch sometimes invoked as shell command -> 'apply_patch: command not found' #2235
• apply_patch writes to session CWD instead of requested workspace, causing edits in wrong repo #3749

[github-actions]

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

• v0.121.0: apply_patch fails with use_legacy_landlock=true and prompts sandbox retry for workspace edits #18069
• Codex keeps asking "retry without sandbox" even when the file edit already succeeded #18053
• Regression in 0.118.0: apply_patch enters patch-approval loop (command failed; retry without sandbox?) while 0.117.0 works #16407
• functions.apply_patch fails with No such file or directory after patch approval even though apply_patch works via shell #17778

Powered by Codex Action

[Kulsgam]

Version 0.115 onwards use a different sandboxing mechanism. The only fix I could find for this is to downgrade to 0.114 and run codex with --ask-for-approval on-request --sandbox workspace-write.

Note that I'm using WSL 2 on Windows to run Codex CLI. Run it as administrator if it does not work