Summary

The macOS seatbelt sandbox profile applied to exec_shell (Agent mode, default) denies read/write access to ~/.cargo/registry/cache/ and ~/.cargo/registry/src/. As a result, cargo publish fails for any non-leaf workspace crate when run from inside a deepseek TUI session.

Repro

1. From inside a deepseek TUI session in this repo, run bash scripts/release/publish-crates.sh (or cargo publish -p deepseek-config, etc.).
2. The first leaf crate (deepseek-secrets — no internal deps) publishes successfully because no registry download is required.
3. Every subsequent crate fails: cargo publish triggers a verification build that needs to read the registry cache, which the sandbox blocks.

Why it matters

scripts/release/publish-crates.sh is the documented release flow for crates.io publishing. Right now it cannot run inside the TUI — you must drop to a real shell.

Fix options

(a) Extend the default seatbelt allow-list in crates/tui/src/sandbox/seatbelt.rs to include read+write on ~/.cargo/registry/{cache,src}/ and ~/.cargo/git/. Lowest-friction; matches Codex CLI's behavior.

(b) Detect cargo-publish-class commands in crates/tui/src/command_safety.rs (cargo publish, cargo install, cargo update) and route them through a "needs registry access" approval that grants registry-cache write for that single command.

(c) Document a workaround: /trust + run from a shell outside TUI. (Already partially possible — /trust widens the workspace boundary but does not relax the seatbelt profile itself.)

Recommend (a). The registry cache is not security-sensitive in any meaningful sense — it's downloaded crate sources from crates.io, signed by the registry. Blocking it just breaks legitimate workflows.

Environment

• macOS Darwin 25.1.0
• deepseek 0.8.9 (compiled from feat/v0.8.9 branch)
• Mode: Agent (also reproduces in YOLO since YOLO still applies the seatbelt profile to exec_shell)