Skip to content

Conversation

@t-kalinowski
Copy link
Member

Motivation

Currently, running commands like devtools::test() in a sandbox on macOS fails because processx errors during .onLoad. The failure is caused by macOS Seatbelt deny rules for specific sysctl calls that ps::ps_handle() and ps::ps_boot_time() trigger.

Problem (MRE)

Testing with the Codex CLI sandbox:

codex sandbox macos --full-auto -- Rscript -e 'devtools::test()'

produces:

❯ codex sandbox macos --full-auto -- Rscript -e 'devtools::test()'
ℹ Testing processx
Error: Could not find tools necessary to compile a package
Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
Execution halted

Or in another package, a more direct error:

❯ codex sandbox macos --full-auto -- Rscript -e 'devtools::test()'
ℹ Testing quickr
Starting 5 test processes.
Error: .onLoad failed in loadNamespace() for 'processx', details:
  call: NULL
  error: Operation not permitted
Execution halted

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 sysctl calls (see https://github.com/openai/codex/blob/main/codex-rs/core/src/seatbelt_base_policy.sbpl#L26-L74); KERN_PROC_PID / kern.proc.pid.* and KERN_BOOTTIME / kern.boottime are not on it.

Fix

  • Gate the boot-time initialization in .onLoad() to Linux only.
  • Avoid macOS sysctl(KERN_PROC_PID) / sysctl(KERN_BOOTTIME) calls that fail under the Codex Seatbelt sandbox.

processx only seems to use this initialization routine on Linux (it’s used to convert /proc start-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).

- Avoid macOS seatbelt sysctl denials on load.
@t-kalinowski
Copy link
Member Author

The failing tests look like they are unrelated snapshot errors that need to be updated for the new testthat version. If you'd like, I can do that here, or in a separate PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant