Repository navigation
macOS: Agent Bash git fails with "unable to load libxcrun" under the Seatbelt sandbox #5260
Description
What happened
What happened
Any git command run through the Agent Bash tool on macOS fails:
xcrun: error: unable to load libxcrun (dlopen(/Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib, 0x0005): tried: '/Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib' (file system sandbox blocked open()), '/System/Volumes/Preboot/Cryptexes/OS/Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib' (no such file), '/Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib' (file system sandbox blocked open())).
Expected: git runs normally inside the workspace-write sandbox.
Cause
On macOS /usr/bin/git is Apple's shim, not a real git. It execs fine ((allow process*)), but at runtime it resolves the active developer directory via xcode-select -p and dlopens libxcrun.dylib from /Applications/Xcode.app/Contents/Developer/usr/lib/.
The Seatbelt base policy denies by default and only grants /System, /usr, /bin, /sbin, and /Library/Apple:
https://github.com/apache/maka/blob/main/packages/runtime/src/sandbox/macos-seatbelt.ts#L34
/Applications is never granted, so the dlopen is blocked.
The darwin path context for shell commands only contributes the Node runtime's own roots:
https://github.com/apache/maka/blob/main/packages/runtime/src/builtin-tools.ts#L833
executableRoots: macosRuntimeExecutableRoots(process.execPath),which resolves to the Node install directory plus /opt/homebrew / /usr/local — and only when process.execPath itself lives there. No developer toolchain root is ever added.
Why the existing Mach-O dependency resolver doesn't catch it
packages/runtime/src/filesystem-worker/macos-executable-dependencies.ts walks Mach-O dependencies and grants what it finds, but it cannot help here:
- It is only wired to the filesystem worker (
filesystem-worker/launch-spec.ts:86), not to Agent Bash. libxcrun.dylibisdlopened at runtime, not anLC_LOAD_DYLIBof/usr/bin/git(otool -L /usr/bin/gitshows onlylibxcselect.dylibandlibSystem.B.dylib), so a static walk cannot see it.isSystemRuntimePath()in the same file would skip it regardless.
How to reproduce
- macOS with Xcode installed, so
xcode-select -preturns/Applications/Xcode.app/Contents/Developer. - Ensure
gitresolves to/usr/bin/git(Apple Git), not a Homebrew build. - Ask the agent to run any
gitcommand, e.g.git status.
Users whose PATH resolves git to /opt/homebrew/bin/git are unaffected, because that is a real binary rather than the Apple shim — which is why this is not universal.
Suggested fix
Add the active developer toolchain root (from xcode-select -p, falling back to /Library/Developer/CommandLineTools) to both executableRoots and runtimeReadableRoots in the darwin branch of the Bash path context. Roots must go through resolveRootPath canonicalization, since Seatbelt matches kernel-resolved paths.
Related gaps found while investigating
macosRuntimeExecutableRootsonly adds/opt/homebrewwhen Node itself lives under/opt/homebrew. On machines where Node comes from mise or nvm, Homebrew-installed tools (git,rg, ...) are not granted either. Detecting these roots fromPATHinstead of inferring them fromprocess.execPathwould be more robust.- After granting the Xcode root,
gitstill fails withfatal: unable to access '/Users/keli/.gitconfig': Operation not permitted. Theworkspace-writeprofile grants no$HOMEread, so git remains broken for anyone with a global gitconfig.
How to reproduce
How to reproduce
- macOS with Xcode installed, so
xcode-select -preturns/Applications/Xcode.app/Contents/Developer. - Ensure
gitresolves to/usr/bin/git(Apple Git), not a Homebrew build. - Ask the agent to run any
gitcommand, e.g.git status.
Users whose PATH resolves git to /opt/homebrew/bin/git are unaffected, because that is a real binary rather than the Apple shim — which is why this is not universal.
Environment
Environment
- Maka commit:
d2e6c1f27 - OS: macOS 26.6.2 (arm64)
- Surface: Desktop
- Node.js: v24.21.0
git:git version 2.50.1 (Apple Git-155)at/usr/bin/gitxcode-select -p:/Applications/Xcode.app/Contents/Developer
Logs, screenshots, or additional context
git log -7 --pretty=format:'%h|%an|%ad|%s' --date=iso
xcrun: error: unable to load libxcrun (dlopen(/Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib, 0x0005): tried: '/Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib' (file system sandbox blocked open()), '/System/Volumes/Preboot/Cryptexes/OS/Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib' (no such file), '/Applications/Xcode.app/Contents/Developer/usr/lib/libxcrun.dylib' (file system sandbox blocked open())).
Activity
Dante-dan commentedon Sep 13, 2026
I traced this against the current Bash sandbox path and the withdrawn #4279, including the review findings around broad developer roots and disabled Git configuration.
I plan to keep the replacement deliberately narrow:
DEVELOPER_DIRor a bounded/usr/bin/xcode-select -plookup, canonicalize it, validate the actual toolchain layout, and reject root, home, missing, looping, or non-toolchain selections;/Applications,$HOME, or arbitrary PATH prefixes;GIT_CONFIG_GLOBAL=/dev/null, including regression coverage for referenced excludes;I’ll keep PATH-wide executable discovery out of this change because it requires a separate, bounded dependency model.
Dante-dan commentedon Sep 13, 2026
take