macOS: let sandboxed codex doctor collect security history through an authorized host diagnostic
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
What variant of Codex are you using?
Codex CLI 0.152.0, invoked through a Codex Desktop agent task with a Seatbelt sandbox and denied-read rules. macOS 27.0, build 26A5425a, arm64.
What feature would you like to see?
Allow codex doctor running inside an agent sandbox to obtain the macOS desktop security assessment through an authorized host operation. The trusted host would run the fixed Gatekeeper/XProtect probes outside the child sandbox and return their classified results. Doctor and ordinary agent commands would retain their existing sandbox restrictions.
The desired outcome is a completed desktop.security.enforcement result in Doctor's local output, including JSON, without manually switching terminals or submitting a feedback upload.
Current limitation
Doctor directly launches /usr/bin/log to inspect recent security history. Replaying its exact query inside the agent sandbox produced:
exit code: 64
stderr: log: Cannot run while sandboxed
stdout: empty
elapsed: approximately 0.02 seconds
Doctor maps this failure to:
recent macos security enforcement history was unavailable — check access to macos unified security logs and rerun codex doctor
The probe failed before its timeout or output limit. The installed macOS log binary checks for sandboxing before processing the query. Simply adding filesystem access cannot satisfy that check.
Ordinary command escalation is also insufficient when denied-read rules are active: Codex intentionally retains the sandbox to preserve those rules. This feature should provide a separately authorized, narrowly scoped diagnostic capability while preserving that behavior.
Proposed behavior
- When an authorized host diagnostic capability is available, sandboxed Doctor requests the macOS desktop security check through a scoped channel. An inherited request channel is one possible design; the specific transport can follow existing host/executor conventions.
- An already-running trusted host on the Mac being diagnosed executes the fixed probes outside the child sandbox, using host-resolved executables, application identity, query, environment, and limits.
- The host classifies the results and returns a bounded structured assessment. Raw system-log records remain on the host. Doctor reports the collection time and host-assisted origin alongside the result.
- If the capability is disallowed, absent, or unable to read the logs, Doctor reports that specific incomplete-assessment reason. It does not silently relax policy or report success.
Starting another helper from the sandboxed Doctor process alone would not provide the required separation: the collecting host must already have access outside that sandbox.
Acceptance criteria
- A macOS integration test demonstrates that the direct sandboxed log query is refused while an authorized host-assisted check returns the expected assessment. Ordinary commands remain sandboxed and denied-read paths remain inaccessible.
- The host authorizes this diagnostic separately under applicable user and managed policy. Denial performs no host probe; existing command-escalation restrictions remain intact.
- The request cannot select arbitrary commands, predicates, paths, or environment variables, and does not expose a general app-server or exec-server connection to sandboxed children.
- Host results are bound to the requesting task and diagnosed Mac/application, have a collection timestamp, and preserve Gatekeeper and security-event outcomes. Missing or truncated evidence never becomes a clean assessment.
- Probe time, output, concurrent work, and cancellation are bounded. Tests cover unavailable hosts, permission refusal, timeout, truncation, successful empty history, and detected enforcement events.
- Collection is local and has no feedback-upload side effect. Standalone Doctor without a host capability retains a direct-probe path with explicit failure reasons.
Additional information
The proposal is grounded in an inspection of upstream main at d2d5b70241fb448044c1c088a977cc720d70443a, dated September 4, 2026:
- Host-side Doctor collection already exists.
doctor_feedback_report()launchescodex doctor --json --feedbackdirectly from app-server with a 25-second timeout. Its current caller attaches the report to a feedback upload; it is not a standalone diagnostic-read API. This provides collection precedent, conditional on the app-server host itself having log access. - Scoped parent/child IPC already exists.
codex-shell-escalationuses an inherited socket descriptor to request policy-controlled execution by the parent. It demonstrates the process separation, but is not an existing Doctor diagnostic capability. - Denied-read protections must be preserved.
unsandboxed_execution_allowed()and its caller deliberately keep escalated commands sandboxed when denied reads are configured. This rule also exists in0.152.0and matches the observed escalated retries remaining sandboxed. - Existing public APIs do not supply this result.
server/diagnosticsreturns process statistics and gauges.command/execuses the effective execution policy. Neither provides a dedicated, authorized macOS security assessment to sandboxed Doctor; its current probe still launches the log command locally.
These are implementation building blocks, not a claim that host-assisted Doctor already works. The sandboxed query was reproduced; a successful host-side query and the proposed request/response flow were not tested. The original reported warning's invocation context was not established, so this report does not attribute every occurrence to sandboxing.
Related: #39067 introduced the security check. #33145 requests accurate classification of sandbox-limited Doctor checks; this proposal additionally requests collection through an authorized host. #42821 improves managed-policy reporting but does not provide that collection path.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with codex-rs/cli/src/doctor/desktop/macos_security.rs, app-server/src/request_processors/feedback_doctor_report.rs, core/src/tools/sandboxing.rs, and the codex-shell-escalation README to understand the existing probe, host collection, and sandbox rules. Validate the direct sandboxed query first, then define the scoped host request and integration tests so bounded, policy-authorized results are returned without exposing raw logs or relaxing denied-read protections.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos, rust
- Domain
- cli, operating-systems, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100