Skip to content

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

Description

@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())

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingperformanceregressionBehaviors that worked in previous versions but were broken due to an updatesandboxIssues related to permissions or sandboxing

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions