Summary
Since v0.6.0's darwin_seatbelt rework ("Sandboxed macOS agents now boot reliably"), every session on the pi harness fails within seconds with:
runner_error: inner executor error: Pi process ended without response. Stderr: darwin_seatbelt: helper interpreter at '.../uv/tools/omnigent/bin/python' resolves under the unsafe ancestor '/Users'; granting a narrow read-only ...
The pi CLI (@earendil-works/pi-coding-agent, a node program: /opt/homebrew/bin/pi -> ../lib/node_modules/.../cli.js, shebang #!/usr/bin/env node, node at /opt/homebrew/bin/node -> ../Cellar/node/26.3.0/bin/node) runs fine outside the sandbox with the exact spawn args (pi --mode rpc --no-session --model ...). The same seats worked jailed on v0.4.0.
Evidence it is runner-level and config-unreachable
- Adding
/opt/homebrew to the spec's os_env.sandbox.read_paths → identical failure.
- Setting the spec's
os_env.sandbox.type: none → identical failure, and the darwin_seatbelt "helper interpreter" warnings still appear in stderr — i.e. a seatbelt wrap is applied to the harness subprocess regardless of the spec's sandbox setting.
- claude-sdk sessions on the same host/runner (python-based harness) boot and run fine — the new
_add_topmost "helper interpreter" logic detects and grants Python install roots, but nothing equivalent exists for node.
Impact
All pi-harness agents are unusable on macOS under v0.6.0 (tested: MiniMax, OpenRouter-provider, and local-Ollama backed pi specs — all fail identically at spawn). Downgrading to v0.5.1 is blocked once the server DB has been migrated by a 0.6.0 boot (no downgrade path), so affected deployments are stuck.
Suggested fix
Extend the sandbox's helper/interpreter detection to non-Python interpreter chains (node at minimum: resolve the CLI's shebang interpreter and grant its install root + symlink hops, like #2743 did for exec-chain symlinks) — or honor the spec's sandbox.type: none for the harness subprocess wrap, or expose an explicit extra-grants knob for the runner-level wrap.
Observed on omnigent 0.6.0 (built 2026-07-21), macOS 15 arm64 (M4), uv tool install, pi CLI 0.79.6.
Summary
Since v0.6.0's darwin_seatbelt rework ("Sandboxed macOS agents now boot reliably"), every session on the pi harness fails within seconds with:
The pi CLI (
@earendil-works/pi-coding-agent, a node program:/opt/homebrew/bin/pi -> ../lib/node_modules/.../cli.js, shebang#!/usr/bin/env node, node at/opt/homebrew/bin/node -> ../Cellar/node/26.3.0/bin/node) runs fine outside the sandbox with the exact spawn args (pi --mode rpc --no-session --model ...). The same seats worked jailed on v0.4.0.Evidence it is runner-level and config-unreachable
/opt/homebrewto the spec'sos_env.sandbox.read_paths→ identical failure.os_env.sandbox.type: none→ identical failure, and the darwin_seatbelt "helper interpreter" warnings still appear in stderr — i.e. a seatbelt wrap is applied to the harness subprocess regardless of the spec's sandbox setting._add_topmost"helper interpreter" logic detects and grants Python install roots, but nothing equivalent exists for node.Impact
All pi-harness agents are unusable on macOS under v0.6.0 (tested: MiniMax, OpenRouter-provider, and local-Ollama backed pi specs — all fail identically at spawn). Downgrading to v0.5.1 is blocked once the server DB has been migrated by a 0.6.0 boot (no downgrade path), so affected deployments are stuck.
Suggested fix
Extend the sandbox's helper/interpreter detection to non-Python interpreter chains (node at minimum: resolve the CLI's shebang interpreter and grant its install root + symlink hops, like #2743 did for exec-chain symlinks) — or honor the spec's
sandbox.type: nonefor the harness subprocess wrap, or expose an explicit extra-grants knob for the runner-level wrap.Observed on omnigent 0.6.0 (built 2026-07-21), macOS 15 arm64 (M4), uv tool install, pi CLI 0.79.6.