Issue Station
Sign In
Tools hereToolbox

codex - ✅(Solved) Fix --add-dir does not grant write access on Ubuntu (workspace-write); writable_roots works [1 pull requests, 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#18448•Fetched 2026-04-18 05:54:42
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
ssaattwwssaattww
Participants
github-actions[bot]github-actions[bot]ssaattwwssaattww
Timeline (top)
labeled ×4commented ×1unlabeled ×1

Error Message

  • Write fails with sandbox permission error

Fix Action

Fix / Workaround

  • The issue is not related to filesystem permissions (verified with test -w)
  • The issue is not resolved by --enable use_legacy_landlock
  • /tmp remains writable in the same session
  • This appears to be a CLI-level issue where --add-dir is not properly propagated to sandbox configuration

PR fix notes

PR #18459: Test --add-dir workspace-write shell writes

Description (problem / solution / changelog)

Summary

Refs #18448.

--add-dir is intended to behave like sandbox_workspace_write.writable_roots, but the existing codex-exec coverage only checked that the flag was accepted. That left the reported failure mode uncovered: a model-issued shell command could still be unable to write into the added directory while workspace-write sandboxing was active.

This PR adds an end-to-end codex-exec regression test that starts a mocked model turn, has the shell tool write into a temporary directory supplied via --add-dir, and verifies the file is created.

Changed files

  • codex-rs/exec/tests/suite/add_dir.rs (modified, +61/-0)
RAW_BUFFERClick to expand / collapse

What version of Codex CLI is running?

codex-cli 0.117.0 and codex-cli 0.121.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4-mini (low)

What platform is your computer?

Linux 6.8.0-107-generic x86_64 x86_64

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

VSCode

What issue are you seeing?

--add-dir does not grant write access to the specified directory when using -s workspace-write.

Even though the directory is writable at the OS level, Codex cannot write to it. However, configuring the same path via writable_roots in config.toml works as expected.

This suggests that --add-dir is not correctly applied to sandbox writable roots.

What steps can reproduce the bug?

  1. Ensure the directory is writable:

ls -ld /home/ibis/AI/CodexSkill
test -w /home/ibis/AI/CodexSkill && echo WRITABLE

  1. Start Codex with:

codex --add-dir /home/ibis/AI/CodexSkill -s workspace-write

  1. Ask Codex to create a file in that directory

Result:

  • Write fails with sandbox permission error
  • Writing to /tmp succeeds
  1. Add the same path to config:

[sandbox_workspace_write]
writable_roots = ["/home/ibis/AI/CodexSkill"]

  1. Restart Codex and repeat

Result:

  • Writing succeeds

What is the expected behavior?

--add-dir should behave equivalently to adding the path to writable_roots, and allow write access to the specified directory.

What is the actual behavior?

--add-dir does not grant write access, even though:

  • The directory is writable at OS level
  • The same path works via writable_roots

Additional information

  • The issue is not related to filesystem permissions (verified with test -w)
  • The issue is not resolved by --enable use_legacy_landlock
  • /tmp remains writable in the same session
  • This appears to be a CLI-level issue where --add-dir is not properly propagated to sandbox configuration

extent analysis

TL;DR

The issue can be worked around by configuring the directory path via writable_roots in config.toml instead of using the --add-dir flag.

Guidance

  • Verify that the directory is indeed writable at the OS level using test -w as shown in the reproduction steps.
  • Try adding the directory path to writable_roots in config.toml as a workaround, as this has been shown to work in the provided example.
  • Investigate the difference in behavior between --add-dir and writable_roots to understand why the former is not granting write access as expected.
  • Check the Codex CLI documentation to see if there are any known issues or limitations with the --add-dir flag.

Example

No code snippet is provided as the issue appears to be related to configuration and command-line flags rather than code.

Notes

The issue seems to be specific to the --add-dir flag and its interaction with sandbox configuration. The fact that /tmp remains writable suggests that the issue is not a general permissions problem.

Recommendation

Apply workaround: use writable_roots in config.toml instead of --add-dir flag, as this has been shown to work in the provided example. This allows write access to the specified directory without relying on the potentially buggy --add-dir flag.

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…
#permission error#SSR setup#ISR setup#authentication setup#request error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING