Sandbox regression: macOS open command fails with procNotFound (-600)

Description

The macOS open command (used to open files/URLs in GUI apps) no longer works inside the Claude Code sandbox. It fails with:

Error Domain=NSOSStatusErrorDomain Code=-600 "procNotFound: no eligible process with specified descriptor"
UserInfo={_LSLine=392, _LSFunction=_LSAnnotateAndSendAppleEventWithOptions, _LSFile=LSOpenCore.mm, _LSErrorMessage=procNotFound}

This used to work in previous versions of Claude Code with the same sandbox configuration. The command works immediately when run with dangerouslyDisableSandbox: true.

Environment

• OS: macOS (Darwin 25.4.0)
• Terminal: iTerm.app (GUI session, not SSH)
• Claude Code model: opus 4.6 (1M context)

Sandbox configuration

// .claude/settings.json (project)
{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "writablePaths": ["/Users/.../project"],
    "network": { "allowLocalBinding": true }
  }
}

// .claude/settings.local.json includes Bash(open:*) in permissions.allow
// and autoAllowBashIfSandboxed: true

Reproduction steps

1. Have Chrome (or any GUI app) running
2. Run in Claude Code: open -a "Google Chrome" somefile.html
3. Observe the -600 procNotFound error
4. Run the same command with dangerouslyDisableSandbox: true -- it succeeds

Analysis

The Bash(open:*) permission is granted, so the command itself is allowed to execute. The failure happens at the OS level: the Seatbelt sandbox profile blocks the Launch Services IPC (Mach port communication) that open uses to dispatch to GUI apps. This is a regression -- the sandbox previously allowed this IPC.

Evidence that the GUI session is valid:

• TERM_PROGRAM=iTerm.app (running in a real GUI terminal)
• Chrome DevTools MCP can connect to Chrome via TCP debug port (Chrome is running)
• launchctl print gui/$(id -u) shows an active login session

Impact

open is a common, non-destructive, read-only command used to:

• Open HTML files/mockups in a browser
• Open documentation URLs
• Open files in their default app for review

Blocking it in the sandbox forces users to either approve dangerouslyDisableSandbox for every invocation or use workarounds (e.g., Chrome DevTools MCP).

Expected behavior

open should work inside the sandbox, as it did in previous versions. It is a read-only operation that does not modify the filesystem or network -- it just tells Launch Services to hand a file to an already-running app.

Alternatively, if this restriction is intentional, there should be a sandbox configuration option to allow Launch Services IPC (similar to allowLocalBinding for network).