feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
As stated in `codex-rs/README.md`:
Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
run it. For a number of users, this runtime requirement inhibits
adoption: they would be better served by a standalone executable. As
maintainers, we want Codex to run efficiently in a wide range of
environments with minimal overhead. We also want to take advantage of
operating system-specific APIs to provide better sandboxing, where
possible.
To that end, we are moving forward with a Rust implementation of Codex
CLI contained in this folder, which has the following benefits:
- The CLI compiles to small, standalone, platform-specific binaries.
- Can make direct, native calls to
[seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
[landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
order to support sandboxing on Linux.
- No runtime garbage collection, resulting in lower memory consumption
and better, more predictable performance.
Currently, the Rust implementation is materially behind the TypeScript
implementation in functionality, so continue to use the TypeScript
implmentation for the time being. We will publish native executables via
GitHub Releases as soon as we feel the Rust version is usable.
2025-04-24 13:31:40 -07:00
|
|
|
(version 1)
|
|
|
|
|
|
|
|
|
|
; inspired by Chrome's sandbox policy:
|
|
|
|
|
; https://source.chromium.org/chromium/chromium/src/+/main:sandbox/policy/mac/common.sb;l=273-319;drc=7b3962fe2e5fc9e2ee58000dc8fbf3429d84d3bd
|
|
|
|
|
|
|
|
|
|
; start with closed-by-default
|
|
|
|
|
(deny default)
|
|
|
|
|
|
|
|
|
|
; child processes inherit the policy of their parent
|
|
|
|
|
(allow process-exec)
|
|
|
|
|
(allow process-fork)
|
|
|
|
|
(allow signal (target self))
|
|
|
|
|
|
|
|
|
|
(allow file-write-data
|
|
|
|
|
(require-all
|
|
|
|
|
(path "/dev/null")
|
|
|
|
|
(vnode-type CHARACTER-DEVICE)))
|
|
|
|
|
|
|
|
|
|
; sysctls permitted.
|
|
|
|
|
(allow sysctl-read
|
|
|
|
|
(sysctl-name "hw.activecpu")
|
|
|
|
|
(sysctl-name "hw.busfrequency_compat")
|
|
|
|
|
(sysctl-name "hw.byteorder")
|
|
|
|
|
(sysctl-name "hw.cacheconfig")
|
|
|
|
|
(sysctl-name "hw.cachelinesize_compat")
|
|
|
|
|
(sysctl-name "hw.cpufamily")
|
|
|
|
|
(sysctl-name "hw.cpufrequency_compat")
|
|
|
|
|
(sysctl-name "hw.cputype")
|
|
|
|
|
(sysctl-name "hw.l1dcachesize_compat")
|
|
|
|
|
(sysctl-name "hw.l1icachesize_compat")
|
|
|
|
|
(sysctl-name "hw.l2cachesize_compat")
|
|
|
|
|
(sysctl-name "hw.l3cachesize_compat")
|
|
|
|
|
(sysctl-name "hw.logicalcpu_max")
|
|
|
|
|
(sysctl-name "hw.machine")
|
|
|
|
|
(sysctl-name "hw.ncpu")
|
|
|
|
|
(sysctl-name "hw.nperflevels")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_BF16")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_DotProd")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_FCMA")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_FHM")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_FP16")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_I8MM")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_JSCVT")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_LSE")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_RDM")
|
|
|
|
|
(sysctl-name "hw.optional.arm.FEAT_SHA512")
|
|
|
|
|
(sysctl-name "hw.optional.armv8_2_sha512")
|
|
|
|
|
(sysctl-name "hw.memsize")
|
|
|
|
|
(sysctl-name "hw.pagesize")
|
|
|
|
|
(sysctl-name "hw.packages")
|
|
|
|
|
(sysctl-name "hw.pagesize_compat")
|
|
|
|
|
(sysctl-name "hw.physicalcpu_max")
|
|
|
|
|
(sysctl-name "hw.tbfrequency_compat")
|
|
|
|
|
(sysctl-name "hw.vectorunit")
|
|
|
|
|
(sysctl-name "kern.hostname")
|
|
|
|
|
(sysctl-name "kern.maxfilesperproc")
|
|
|
|
|
(sysctl-name "kern.osproductversion")
|
|
|
|
|
(sysctl-name "kern.osrelease")
|
|
|
|
|
(sysctl-name "kern.ostype")
|
|
|
|
|
(sysctl-name "kern.osvariant_status")
|
|
|
|
|
(sysctl-name "kern.osversion")
|
|
|
|
|
(sysctl-name "kern.secure_kernel")
|
|
|
|
|
(sysctl-name "kern.usrstack64")
|
|
|
|
|
(sysctl-name "kern.version")
|
|
|
|
|
(sysctl-name "sysctl.proc_cputype")
|
|
|
|
|
(sysctl-name-prefix "hw.perflevel")
|
|
|
|
|
)
|
Fix MacOS multiprocessing by relaxing sandbox (#1808)
The following test script fails in the codex sandbox:
```
import multiprocessing
from multiprocessing import Lock, Process
def f(lock):
with lock:
print("Lock acquired in child process")
if __name__ == '__main__':
lock = Lock()
p = Process(target=f, args=(lock,))
p.start()
p.join()
```
with
```
Traceback (most recent call last):
File "/Users/david.hao/code/codex/codex-rs/cli/test.py", line 9, in <module>
lock = Lock()
^^^^^^
File "/Users/david.hao/.local/share/uv/python/cpython-3.12.9-macos-aarch64-none/lib/python3.12/multiprocessing/context.py", line 68, in Lock
return Lock(ctx=self.get_context())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/david.hao/.local/share/uv/python/cpython-3.12.9-macos-aarch64-none/lib/python3.12/multiprocessing/synchronize.py", line 169, in __init__
SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
File "/Users/david.hao/.local/share/uv/python/cpython-3.12.9-macos-aarch64-none/lib/python3.12/multiprocessing/synchronize.py", line 57, in __init__
sl = self._semlock = _multiprocessing.SemLock(
^^^^^^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 1] Operation not permitted
```
After reading, adding this line to the sandbox configs fixes things -
MacOS multiprocessing appears to use sem_lock(), which opens an IPC
which is considered a disk write even though no file is created. I
interrogated ChatGPT about whether it's okay to loosen, and my
impression after reading is that it is, although would appreciate a
close look
Breadcrumb: You can run `cargo run -- debug seatbelt --full-auto <cmd>`
to test the sandbox
2025-08-03 06:59:26 -07:00
|
|
|
|
|
|
|
|
; Added on top of Chrome profile
|
|
|
|
|
; Needed for python multiprocessing on MacOS for the SemLock
|
|
|
|
|
(allow ipc-posix-sem)
|