Sandbox mode always set to readonly even if set to workspace_write in config.toml

Resolved 💬 3 comments Opened Nov 14, 2025 by Nardol Closed Feb 23, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.58.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.1-codex-medium

What platform is your computer?

Linux 6.12.43+deb12-amd64 x86_64 unknown

What issue are you seeing?

My config.toml is as following:

approval_policy = "on-failure"
model = "gpt-5.1-codex"
model_reasoning_effort = "medium"
sandbox_mode = "workspace-write"

[features]
web_search_request = true

[sandbox_workspace_write]
writable_roots = ["/home/xxx/.cache"]
network_access = true

[notice]
hide_gpt5_1_migration_prompt = true

If I run codex then type /status it displays the sandbox is workspace-write as expected but when typing /approval readlonly is selected.
It is confirmed while executing file edition, I have to confirm every file modifications even in the workspace.
The same occurs if I remove my writable roots or approval policy.

What steps can reproduce the bug?

Uploaded thread: 019a82a6-b3dd-7e61-8b7a-d01336fd0e84

What is the expected behavior?

Workspace should be writable and I should not have to confirm everything

Additional information

I think this issue was introduced in version 0.57.0 but not sure.
Same applies in both untrusted or on-failure modes.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 9 months ago

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

  • #6428
  • #6374
  • #6090
  • #5202

Powered by Codex Action

Zaczero · 9 months ago

Possibly related to https://github.com/openai/codex/issues/3129 It seems like /approvals modes are not integrating with custom config.toml. Setting mode to readonly is only a visual glitch and until mode is changed, the config.toml settings are used.

etraut-openai contributor · 6 months ago

I think this has been fixed. If you're still seeing a similar issue with the latest version of the CLI, please let us know.