macOS Seatbelt sandbox blocks libproc/sysmon process listing for ps/pgrep

Summary

Inside Codex CLI on macOS, ps, pgrep, top, lsof and any libproc-backed process query fail with sysmon request failed with error: sysmond service not found / Cannot get process list. The Seatbelt profile generated by Codex doesn't allow mach-lookup of com.apple.sysmond.system, which is what libproc uses for process inspection.

There is currently no documented config.toml knob in Codex CLI 0.131.0 to whitelist this specific mach service or to mark read-only process-inspection commands as trusted. The only escape is sandbox_mode = "danger-full-access", which removes all file/network protections — not a viable trade for the use case.

Reproducer

# Environment:
# macOS Darwin 25.3 (Apple Silicon)
# Codex CLI 0.131.0
# ~/.codex/config.toml:
#   sandbox_mode = "workspace-write"
#   approval_policy = "never"
#   default_permissions = "secret-fence"
#   [permissions.secret-fence.filesystem]
#   ":root" = "read"
#   "/Users/<you>/.mcp-creds/**" = "none"
#   "/Users/<you>/.ssh/**"       = "none"

# Inside a Codex session, ask it to run:
pgrep -fl workspace-mcp
ps -ax | head

# Result:
sysmon request failed with error: sysmond service not found
pgrep: Cannot get process list

lsof still works (it does not depend on sysmond), and live MCP tool calls work — but anything libproc-backed is dead.

Root cause

Confirmed from upstream source:

• seatbelt_base_policy.sbpl (compiled in via include_str!) does not include (allow mach-lookup (global-name "com.apple.sysmond.system")).
• seatbelt.rs assembles the profile programmatically and passes it to /usr/bin/sandbox-exec -p <profile>. The profile is not written to disk, so end users cannot patch it without forking and rebuilding Codex CLI.
• The published Seatbelt mach allowlists do include services like com.apple.SecurityServer, com.apple.networkd, and com.apple.trustd.agent — but not com.apple.sysmond.system.

Use case

Cross-tool diagnostic sessions on macOS where I have both Codex and Claude Code running concurrently, with multiple MCP servers per tool. I needed to verify which tool owned which workspace-mcp child process during a v1.14.1 → v1.21.0 migration. pgrep -fl workspace-mcp is the natural way to do that. Falling back to Claude Code worked, but having to switch tools mid-investigation breaks the workflow.

These commands (ps, pgrep, lsof, top) are read-only — they don't modify state, write files, or exfiltrate secrets beyond a process listing. They're commonly needed during any non-trivial debugging session.

Proposed direction

Two options that would unblock the use case while preserving least-privilege posture:

1. Add a curated default allow for the small set of mach services that read-only process inspection needs (com.apple.sysmond.system is the load-bearing one for ps/pgrep/top). These are read-only, well-understood, and required for any meaningful debugging.

1. Or expose a config.toml key for user-defined mach-lookup allowlists, e.g.:

``toml
[sandbox.macos]
allow_mach_lookups = ["com.apple.sysmond.system"]
``
so users can opt in without disabling the rest of the sandbox.

Option 1 is cleaner. Option 2 is more general but introduces configuration surface.

Neither path requires loosening any file/network restrictions — secret-fence filesystem deny rules would continue to apply unchanged.

Verification plan once a fix lands

codex --version  # confirm fix released
pgrep -fl workspace-mcp   # should succeed
ps -axo pid,ppid,command | head  # should succeed
lsof -nP -iTCP -sTCP:LISTEN | head  # should succeed

# Confirm file fences still enforced:
touch ~/.mcp-creds/sandbox-test  # should fail (denied)
ls ~/.ssh                         # should fail (denied)

Related

• #22405 — same sandbox class (macOS Seatbelt blocking a different syscall, os.sysconf("SC_SEM_NSEMS_MAX")). Both point at the same underlying gap: Seatbelt profile is too restrictive for legitimate read-only system calls and is not user-configurable.