codex - 💡(How to fix) Fix Sandbox denial errors don't tell the agent which paths are writable [1 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#19118Fetched 2026-04-24 06:00:35
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Timeline (top)
labeled ×3closed ×1commented ×1unlabeled ×1

Error Message

ERROR codex_core::tools::router: error=exec_command failed for /bin/zsh -lc "npm test -- --runInBand": SandboxDenied { message: "Error: EPERM: operation not permitted, open '/private/var/folders/.../T/jest_dy/haste-map-...'" }

Code Example

ERROR codex_core::tools::router:
  error=exec_command failed for `/bin/zsh -lc "npm test -- --runInBand"`:
  SandboxDenied { message: "Error: EPERM: operation not permitted,
  open '/private/var/folders/.../T/jest_dy/haste-map-...'" }

---

Sandbox denied write to '/private/var/folders/.../T/jest_dy/...'.
Writable paths: /Users/dev/project (workspace). Use workspace-relative paths for temp files.
RAW_BUFFERClick to expand / collapse

What variant of Codex are you using?

CLI (via codex-acp agent runtime)

What feature would you like to see?

The problem

When the sandbox blocks a write to /tmp or $TMPDIR, the error message contains the raw stderr from the failed command but doesn't include any information about which paths the agent can write to. The agent has no way to self-correct — it doesn't know whether to try the workspace directory, a subdirectory, or give up entirely.

Observed in production (codex-acp) when Jest tried to write its cache to $TMPDIR:

ERROR codex_core::tools::router:
  error=exec_command failed for `/bin/zsh -lc "npm test -- --runInBand"`:
  SandboxDenied { message: "Error: EPERM: operation not permitted,
  open '/private/var/folders/.../T/jest_dy/haste-map-...'" }

The sandbox policy had exclude_tmpdir_env_var: true and exclude_slash_tmp: true, so this denial is correct behavior. But the error gives the agent no hint about what to do instead.

What would help

Include the list of writable paths in the sandbox denial error message. Something like:

Sandbox denied write to '/private/var/folders/.../T/jest_dy/...'.
Writable paths: /Users/dev/project (workspace). Use workspace-relative paths for temp files.

This would let the agent:

  • Redirect temp files to the workspace (e.g. .codex-tmp/)
  • Set TMPDIR to a workspace subdirectory before running commands
  • Understand the constraint without trial and error

Current behavior

UnifiedExecError::SandboxDenied contains the raw command output as message. The writable paths are known at the point where the error is constructed (they come from SandboxPolicy::WorkspaceWrite { writable_roots, .. }), but they're not included in the error.

Impact

Common tools that use temp directories fail silently or with opaque errors under restrictive sandbox policies:

  • Jest (jest-haste-map writes to $TMPDIR)
  • Python (tempfile module defaults to /tmp)
  • Sort, awk, and other Unix tools that write intermediate files to /tmp

The agent retries with different approaches, wasting tool calls and tokens, without understanding the actual constraint.

Platform

  • Darwin 25.3.0 arm64 arm
  • Sandbox: Seatbelt with exclude_tmpdir_env_var: true, exclude_slash_tmp: true
  • Observed via codex-acp agent runtime, codex rust-v0.117.0

Additional information

No response

extent analysis

TL;DR

Modify the UnifiedExecError::SandboxDenied error to include a list of writable paths in the error message.

Guidance

  • Review the SandboxPolicy::WorkspaceWrite struct to understand how writable paths are determined and include this information in the error message.
  • Update the error handling logic to append the list of writable paths to the error message, providing the agent with necessary information to self-correct.
  • Consider adding a fallback mechanism for the agent to redirect temp files to the workspace or set TMPDIR to a workspace subdirectory when encountering a SandboxDenied error.
  • Verify that the updated error message is correctly propagated to the agent and that it can parse and act upon the included writable paths.

Example

// Pseudo-code example, actual implementation may vary
let error = UnifiedExecError::SandboxDenied {
    message: format!(
        "Sandbox denied write to '{}'. Writable paths: {:?}. Use workspace-relative paths for temp files.",
        denied_path,
        writable_roots
    ),
};

Notes

The proposed solution assumes that the SandboxPolicy::WorkspaceWrite struct contains the necessary information about writable paths. If this is not the case, additional changes may be required to determine and include this information in the error message.

Recommendation

Apply workaround: Modify the UnifiedExecError::SandboxDenied error to include a list of writable paths in the error message, allowing the agent to self-correct and redirect temp files to the workspace or set TMPDIR to a workspace subdirectory. This change will improve the agent's ability to handle restrictive sandbox policies and reduce errors.

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