apache / apache/maka

macOS: Agent Bash git fails with "unable to load libxcrun" under the Seatbelt sandbox

Open
#5,260 2 comments 0 reactions 1 assignee Claimed by @Dante-dan View on GitHub
bug
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

Image

```
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.