Fix startup in macOS sandbox-exec sandbox.
#401
+1
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Currently, running commands like
devtools::test()in a sandbox on macOS fails becauseprocessxerrors during.onLoad. The failure is caused by macOS Seatbelt deny rules for specificsysctlcalls thatps::ps_handle()andps::ps_boot_time()trigger.Problem (MRE)
Testing with the Codex CLI sandbox:
codex sandbox macos --full-auto -- Rscript -e 'devtools::test()'produces:
Or in another package, a more direct error:
I tracked this down to the sandbox policy used by Codex (which itself is lightly adapted from Chrome's sandbox policy). There is an explicit allow list for
sysctlcalls (see https://github.com/openai/codex/blob/main/codex-rs/core/src/seatbelt_base_policy.sbpl#L26-L74);KERN_PROC_PID/kern.proc.pid.*andKERN_BOOTTIME/kern.boottimeare not on it.Fix
.onLoad()to Linux only.sysctl(KERN_PROC_PID)/sysctl(KERN_BOOTTIME)calls that fail under the Codex Seatbelt sandbox.processxonly seems to use this initialization routine on Linux (it’s used to convert/procstart-time ticks to absolute time). Gating the block to Linux preserves behavior where needed and avoids macOS sysctl calls that the sandbox denies.At some point in the next few days I'll try to get on Linux to confirm that this is not an issue with the Linux sandbox (which is implemented differently, using Landlock+seccomp).