b8ccfe9b65
this adds some more capabilities to the default sandbox which I feel are safe. Most are in the [renderer.sb](https://source.chromium.org/chromium/chromium/src/+/main:sandbox/policy/mac/renderer.sb) sandbox for chrome renderers, which i feel is fair game for codex commands. Specific changes: 1. Allow processes in the sandbox to send signals to any other process in the same sandbox (e.g. child processes or daemonized processes), instead of just themselves. 2. Allow user-preference-read 3. Allow process-info* to anything in the same sandbox. This is a bit wider than Chromium allows, but it seems OK to me to allow anything in the sandbox to get details about other processes in the same sandbox. Bazel uses these to e.g. wait for another process to exit. 4. Allow all CPU feature detection, this seems harmless to me. It's wider than Chromium, but Chromium is concerned about fingerprinting, and tightly controls what CPU features they actually care about, and we don't have either that restriction or that advantage. 5. Allow new sysctl-reads: ``` (sysctl-name "vm.loadavg") (sysctl-name-prefix "kern.proc.pgrp.") (sysctl-name-prefix "kern.proc.pid.") (sysctl-name-prefix "net.routetable.") ``` bazel needs these for waiting on child processes and for communicating with its local build server, i believe. I wonder if we should just allow all (sysctl-read), as reading any arbitrary info about the system seems fine to me. 6. Allow iokit-open on RootDomainUserClient. This has to do with power management I believe, and Chromium allows renderers to do this, so okay. Bazel needs it to boot successfully, possibly for sleep/wake callbacks? 7. Mach lookup to `com.apple.system.opendirectoryd.libinfo`, which has to do with user data, and which Chrome allows. 8. Mach lookup to `com.apple.PowerManagement.control`. Chromium allows its GPU process to do this, but not its renderers. Bazel needs this to boot, probably relatedly to sleep/wake stuff.
codex-core
This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.
Dependencies
Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this
macOS
Expects /usr/bin/sandbox-exec to be present.
Linux
Expects the binary containing codex-core to run the equivalent of codex debug landlock when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.
All Platforms
Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.