macOS: Agent Bash git fails with "unable to load libxcrun" under the Seatbelt sandbox
- Dominant language
- TypeScript
- Stars
- 5.4k
- Forks
- 502
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 715
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 `dlopen`s `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
```ts
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:
1. It is only wired to the filesystem worker (`filesystem-worker/launch-spec.ts:86`), not to Agent Bash.
2. `libxcrun.dylib` is `dlopen`ed at runtime, not an `LC_LOAD_DYLIB` of `/usr/bin/git` (`otool -L /usr/bin/git` shows only `libxcselect.dylib` and `libSystem.B.dylib`), so a static walk cannot see it.
3. `isSystemRuntimePath()` in the same file would skip it regardless.
## How to reproduce
1. macOS with Xcode installed, so `xcode-select -p` returns `/Applications/Xcode.app/Contents/Developer`.
2. Ensure `git` resolves to `/usr/bin/git` (Apple Git), not a Homebrew build.
3. Ask the agent to run any `git` command, 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
- `macosRuntimeExecutableRoots` only adds `/opt/homebrew` when 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 from `PATH` instead of inferring them from `process.execPath` would be more robust.
- After granting the Xcode root, `git` still fails with `fatal: unable to access '/Users/keli/.gitconfig': Operation not permitted`. The `workspace-write` profile grants no `$HOME` read, so git remains broken for anyone with a global gitconfig.
### How to reproduce
## How to reproduce
1. macOS with Xcode installed, so `xcode-select -p` returns `/Applications/Xcode.app/Contents/Developer`.
2. Ensure `git` resolves to `/usr/bin/git` (Apple Git), not a Homebrew build.
3. Ask the agent to run any `git` command, 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/git`
- `xcode-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())).
```
Contributor guide
Assessment
This issue has not been assessed yet.