codex - 💡(How to fix) Fix [sandbox_workspace_write].network_access = true causes fs sandbox helper write failures on Linux [1 participants]

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

plus

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.8.0-78-generic x86_64 x86_64

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

No response

What issue are you seeing?

When using the legacy permissions model with:

[sandbox_workspace_write]
network_access = true

sandboxed file writes/edits can fail on Linux.

I can reproduce this with codex exec --full-auto: the run starts normally, but when Codex tries to update a file through the fs sandbox helper, it fails with a panic caused by a mismatch between the legacy sandbox policy and the split filesystem/network sandbox policies.

Observed error:

2026-04-17T13:18:54.904978Z ERROR codex_core::tools::router: error={"output":"Failed to read file to update /home/<redacted>/Code/test/ReadMe.md: fs sandbox helper failed with status exit status: 101: thread 'main' (1283634)panicked at linux-sandbox/src/linux_run_main.rs:130:27:legacy sandbox policy must match split sandbox policies: provided=WorkspaceWrite { writable_roots:[AbsolutePathBuf(\"/home/<redacted>/.codex/memories\")], read_only_access: FullAccess, network_access: true,exclude_tmpdir_env_var: false, exclude_slash_tmp: false }, derived=WorkspaceWrite { writable_roots:[AbsolutePathBuf(\"/home/<redacted>/.codex/memories\")], read_only_access: FullAccess, network_access: false,exclude_tmpdir_env_var: false, exclude_slash_tmp: false }note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace","metadata":{"exit_code":1,"duration_seconds":0.0}}

What steps can reproduce the bug?

1. Put the following in ~/.codex/config.toml:

[sandbox_workspace_write]
network_access = true

1. In a directory containing a ReadMe.md, run:

codex exec "Please modify the content in ReadMe.md to xxxxx" --skip-git-repo-check --full-auto

1. Observe that the run fails partway through when Codex attempts to read/update the file via the fs sandbox helper.

What is the expected behavior?

The legacy permissions model should continue to work correctly on Linux when [sandbox_workspace_write].network_access = true is set, and sandboxed file writes should not panic.

Additional information

From Codex digging the source code:

I inspected the source at commit d0047de7c, and this looks like a legacy-vs-split-policy mismatch in the fs sandbox helper path.

Relevant code refs:

• Legacy [sandbox_workspace_write] config is still parsed into a legacy SandboxPolicy::WorkspaceWrite in codex-rs/ config/src/config_toml.rs:634-648.
• In the normal config-loading path, the split policies are derived from that legacy policy:
  • file_system_sandbox_policy = FileSystemSandboxPolicy::from_legacy_sandbox_policy(...)
  • network_sandbox_policy = NetworkSandboxPolicy::from(&sandbox_policy)
  • see codex-rs/core/src/config/mod.rs:1660-1685
• The Linux sandbox helper explicitly checks that the provided legacy policy and the split policies are semantically equivalent, and errors if they differ:
  • mismatch handling: codex-rs/linux-sandbox/src/linux_run_main.rs:292-319
  • semantic comparison includes network policy equality: codex-rs/linux-sandbox/src/linux_run_main.rs:350-360
• In the fs sandbox helper path, the network split policy appears to be forced to Restricted even when the legacy sandbox policy still has network_access = true:
  • codex-rs/exec-server/src/fs_sandbox.rs:51-59
• That seems to explain the panic: the helper receives:
  • a legacy WorkspaceWrite { network_access: true, ... }
  • but split policies whose derived legacy form becomes WorkspaceWrite { network_access: false, ... }

There also seems to be a newer permissions/profile model, but I could not find clear public migration documentation for replacing the legacy [sandbox_workspace_write] config.

From reading the source, the new profile-based model seems to use:

• default_permissions = "..."
• [permissions.<profile>.filesystem]
• [permissions.<profile>.network]

Example test config:

• codex-rs/core/src/config/config_tests.rs:403-420

Network enablement in the new profile model appears to come from:

• codex-rs/core/src/config/permissions.rs:137-145

However, I could not find migration docs that explain:

• how to translate legacy [sandbox_workspace_write]
• what the equivalent of legacy writable_roots is
• whether the new model is intended to fully replace workspace-write + network_access + extra writable_roots

In fact, from the current implementation it looks like profile-based writes outside the workspace root are explicitly rejected:

• implementation: codex-rs/protocol/src/permissions.rs:881-885
• test coverage: codex-rs/core/src/config/config_tests.rs:790-823

So it is currently unclear whether there is any equivalent in the new model for legacy extra writable_roots.