[Bug]: macOS — Orca's agent-session sandbox blocks Orca's own claude-hook.sh (EPERM on every tool call in Orca-hosted Claude Code sessions)

[nathancooper-vm]

Symptom

Every Claude Code session hosted inside Orca on macOS emits repeated hook errors on every tool call:

PreToolUse:Bash hook error
Failed with non-blocking status code: /bin/sh: /Users/<user>/.orca/agent-hooks/claude-hook.sh: Operation not permitted
PostToolUse:Bash hook error
Failed with non-blocking status code: /bin/sh: /Users/<user>/.orca/agent-hooks/claude-hook.sh: Operation not permitted

The hook is the one Orca itself installs into ~/.claude/settings.json (PreToolUse/PostToolUse/Stop/UserPromptSubmit/etc.), pointing at ~/.orca/agent-hooks/claude-hook.sh.

Diagnosis (verified, not speculated)

• Inside an Orca-hosted session, everything under ~/.orca returns EPERM — ls, stat, xattr, and executing the hook (exit 126). This persists even with Claude Code's own command sandbox explicitly disabled (dangerouslyDisableSandbox).
• From a plain Terminal.app, the same directory reads fine with ordinary POSIX permissions (rwxr-xr-x, user-owned), no special TCC grants needed — so it's not file corruption, not Full Disk Access, not MDM (machine isn't enrolled).
• Other fingerprints inside the session point to a seatbelt sandbox profile rather than TCC: ps won't exec, nice() calls fail with EPERM, and /usr/local/bin/orca itself is exec-denied from within the session.
• tccd logs nothing when the denial is triggered.

Conclusion

Orca appears to wrap agent sessions in its own macOS sandbox that denies access to ~/.orca — reasonable protection for your control plane — but the Claude Code hook you install lives inside that denied path. So in exactly the sessions Orca hosts, Orca's sandbox blocks Orca's own hook, and every tool call errors. No permission the user can grant (FDA, TCC toggles, reboot) changes this, since sandbox denials aren't pierced by TCC grants.

Suggested fixes (either works)

1. Whitelist read+exec of ~/.orca/agent-hooks/ in the agent-session sandbox profile — the hooks are the one part of the control plane agents are supposed to execute; or
2. Install the hooks fail-silent by default, e.g.

   if [ -x '<hook>' ]; then /bin/sh '<hook>' 2>/dev/null || exit 0; fi

   so denied contexts no-op instead of erroring on every tool call.

I've applied pattern (2) locally as a workaround, so not urgent for me — but presumably every macOS user running Claude Code inside Orca sees this noise.

Environment

• macOS (Darwin 25.5.0)
• Claude Code, current release
• Orca desktop, current release (version string unavailable from inside the session — the sandbox denies orca --version too, which is part of the same picture)

Possibly related to the hook-runtime drift noted in #1308, but this one is macOS-sandbox-specific and hits the Claude hook rather than Codex.

[confirmconcept]

Additional evidence from another macOS machine (Orca 1.4.139, macOS Darwin 25.5.0): the same seatbelt profile also blocks Apple's developer toolchain, which makes iOS/macOS app development impossible for Orca-hosted agents.

All of the following verified inside an Orca-hosted Claude Code session, with Claude Code's own command sandbox explicitly disabled:

• sandbox_check(getpid(), NULL, 0) returns 1 — the session shell is definitively running under a seatbelt profile.
• Granting Full Disk Access to Orca (and restarting) changes nothing. Expected: seatbelt denials take precedence over TCC grants, so there is no user-side workaround via Privacy & Security settings.
• Denied operations observed, beyond the ~/.orca EPERM already reported:
  • Reading /Library/Preferences — this makes xcodebuild exit 69 ("You have not agreed to the Xcode license agreements") even when the license is accepted, because the license record is unreadable.
  • Executing anything under /Library/Developer/CommandLineTools/usr/bin ("operation not permitted" on exec).
  • simctl cannot load: dyld: Library not loaded ... CoreSimulatorUtilities ... (blocked by sandbox) — simulators are entirely unusable from Orca-hosted agent sessions.
  • ps, proc_pidinfo on non-child processes, sudo, nested sandbox-exec (consistent with the fingerprints in the original report).
• Still working (workaround): pure-SwiftPM builds/tests by invoking the toolchain binaries directly (Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift) with an explicit SDKROOT, which bypasses the license-checking shims.

Impact: any workflow needing xcodebuild app-target builds, simulators, or UI tests cannot run agentically inside Orca.

Request: a per-workspace or per-terminal opt-out of the seatbelt profile, or at minimum profile allowances for reading /Library/Preferences, executing under /Library/Developer, and loading the CoreSimulator private frameworks.