permissions.<id>.network.unix_sockets config not propagated to macOS Seatbelt policy

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

• #25076

Powered by Codex Action

I traced this on current main; the report looks valid, and the gap appears to be the bridge from permission-profile config into the normal Seatbelt runtime invocation, not Seatbelt rule generation itself.

What I found:

• Config parsing accepts profile network Unix-socket policy. codex-rs/core/src/config/permissions.rs maps permissions.<id>.network.unix_sockets into the network permission config.
• Network-proxy configuration can also preserve this data. codex-rs/core/src/config/network_proxy_spec.rs maps requirements.unix_sockets, and codex-rs/core/src/network_proxy_loader.rs maps configured sockets into the managed proxy constraints.
• The Seatbelt layer can already emit the right SBPL for explicit Unix sockets. codex-rs/sandboxing/src/seatbelt_tests.rs has tests covering explicit Unix-socket allowlists, and codex-rs/sandboxing/src/seatbelt.rs passes extra_allow_unix_sockets into proxy_policy_inputs(...) before building the dynamic network policy.
• The debug sandbox CLI wires the command-line flag directly: codex-rs/cli/src/debug_sandbox.rs passes --allow-unix-socket into CreateSeatbeltCommandArgsParams.extra_allow_unix_sockets, which matches the report that the explicit CLI flag works.

The missing bridge seems to be regular permission-profile execution. In codex-rs/core/src/config/mod.rs, the runtime permission conversion keeps the active NetworkSandboxPolicy bit, while a nearby comment says PermissionProfile carries the active network sandbox bit, not the configured proxy/allowlist policy. That means a profile can round-trip the configured allowlist, but the normal Seatbelt invocation can still receive no extra_allow_unix_sockets unless the explicit CLI flag or managed-network/proxy path supplies it.

Minimal fix shape: carry the active profile's concrete Unix-socket allowlist into the runtime sandbox args used for macOS Seatbelt, or extend the runtime network policy/profile value so it includes the concrete socket allowlist instead of only enabled/restricted state. Regression coverage should assert that a config profile containing [permissions.<id>.network.unix_sockets] results in a UNIX_SOCKET_PATH_0 parameter and the corresponding Seatbelt network rules. The lower-level explicit-flag path already appears covered.

Per docs/contributing.md, I am not opening an unsolicited PR; I can submit a focused patch if a maintainer says this direction is welcome.

Still reproduces on codex-cli 0.150.1 (macOS 26.x, arm64), ~15 minor versions after the original report. Same asymmetry: --allow-unix-socket works, the profile config silently no-ops.

Repro, using a host app's control socket directory as the target (~/Library/Application Support/orca, whose CLI connects to o-<pid>-<id>.sock inside it):

SOCKDIR="$HOME/Library/Application Support/orca"

# canonical map schema (#15120) -> no-op
codex sandbox \
  -c 'permissions.uds.extends=":workspace"' \
  -c "permissions.uds.network.unix_sockets={\"$SOCKDIR\"=\"allow\"}" \
  -P uds -- orca status --json
# exit 0, runtime "reachable": false   <- AF_UNIX connect denied

# legacy array form -> also no-op
codex sandbox \
  -c 'permissions.uds2.extends=":workspace"' \
  -c "permissions.uds2.network.allow_unix_sockets=[\"$SOCKDIR\"]" \
  -P uds2 -- orca status --json
# exit 0, "reachable": false

# same profile + the CLI flag -> works
codex sandbox \
  -c 'permissions.uds.extends=":workspace"' \
  -c "permissions.uds.network.unix_sockets={\"$SOCKDIR\"=\"allow\"}" \
  -P uds --allow-unix-socket "$SOCKDIR" -- orca status --json
# exit 0, "reachable": true, real runtimeId

(A profile selected with -P but with no unix_sockets entry behaves identically to the two no-op cases, as expected — included as a control.)

The working flag is unavailable where it's most needed

One impact point I don't think has been raised: --allow-unix-socket and -P exist only on the codex sandbox subcommand. The interactive TUI accepts neither:

$ codex -P uds
error: unexpected argument '-P' found
$ codex --allow-unix-socket "$SOCKDIR"
error: unexpected argument '--allow-unix-socket' found

So for a long-running TUI session — an agent pane that needs to talk to a host application over its AF_UNIX control socket — the config path in this issue is the only available route, and it's the one that doesn't work. The practical consequences are the full-network fallback below, or disabling the sandbox entirely.

This also produces a confusing failure mode downstream: the denial surfaces as connect EPERM, which client CLIs commonly translate into "the app isn't running." I spent a while chasing a phantom dead daemon before finding the actual seatbelt denial (network-outbound <path>.sock). --log-denials was what made it obvious.

Note on the network_access = true fallback

Confirming it still works on 0.150.1, with one gotcha worth recording: sandbox_mode must be set in the same invocation, otherwise the sandbox_workspace_write table is ignored and the switch silently does nothing.

# no effect - IP and AF_UNIX both still denied
codex sandbox -c 'sandbox_workspace_write.network_access=true' -- <cmd>

# works
codex sandbox -c 'sandbox_mode="workspace-write"' \
              -c 'sandbox_workspace_write.network_access=true' -- <cmd>

Positive control that -c itself is honored: -c 'sandbox_mode="danger-full-access"' alone does open the sandbox, so the first form is genuinely a no-op rather than a dropped override. I initially concluded from the first form that network_access was broken too — it isn't; it just needs the mode alongside it. Worth knowing before anyone reads a false negative into it.

Either way, as the original report notes, this opens the entire network namespace, which is exactly what the unix_sockets map was introduced to avoid.