macOS startup is very slow when `sandbox_workspace_write.writable_roots` contains multiple missing paths

Open 💬 0 comments Opened May 1, 2026 by zeyugao

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

plus

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.4.0 arm64 arm

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

_No response_

What issue are you seeing?

On macOS, Codex startup / shell command startup becomes very slow when sandbox_mode = "workspace-write" and [sandbox_workspace_write].writable_roots contains multiple paths that do not exist.

This worked normally in the previous version. The slowdown appears to happen before the command itself runs, likely while applying the macOS Seatbelt sandbox policy via /usr/bin/sandbox-exec.

A likely regression point is the recent Seatbelt metadata protection changes. The macOS Seatbelt adapter currently includes missing writable roots in the generated file-write* policy. Each missing root now also gets .git, .agents, and .codex protected metadata regex carveouts, which may make sandbox-exec policy application unexpectedly slow.

Linux bubblewrap already skips missing writable roots before generating sandbox args, but macOS Seatbelt does not appear to do the same.

What steps can reproduce the bug?

  1. On macOS, configure Codex with workspace-write sandboxing and several missing writable roots:
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = [
  "/tmp/codex-missing-root-1",
  "/tmp/codex-missing-root-2",
  "/tmp/codex-missing-root-3",
]
  1. Ensure those paths do not exist:
rm -rf /tmp/codex-missing-root-1 /tmp/codex-missing-root-2 /tmp/codex-missing-root-3
  1. Start Codex or run a shell command through Codex.
  2. Compare with either:
  • removing the missing paths from writable_roots
  • creating the paths first

Observed behavior: startup / command execution begins much more slowly when multiple configured writable roots are missing.

What is the expected behavior?

Missing writable_roots should not significantly slow down Codex startup or command startup.

Additional information

Potentially relevant code:

  • macOS Seatbelt writable root policy generation:

codex-rs/sandboxing/src/seatbelt.rs
create_seatbelt_command_args() calls get_writable_roots_with_cwd(...) and maps every root into SeatbeltAccessRoot, without filtering missing roots.

  • Linux bubblewrap behavior:

codex-rs/linux-sandbox/src/bwrap.rs
filters writable roots with:

.filter(|writable_root| writable_root.root.as_path().exists())

View original on GitHub ↗