[Feature Request] excludedCommands should also bypass Mach port / IPC restrictions for local app CLIs

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The sandbox's sandbox-exec profile blocks mach-lookup operations, which prevents CLI tools that communicate with running macOS desktop apps via XPC/Mach ports from working. The excludedCommands sandbox setting only bypasses filesystem restrictions, not IPC restrictions — so there's no way to allow these tools to function.

Concrete use case: Obsidian's CLI communicates with the running Obsidian app via XPC. From within Claude Code's sandbox:

# Direct CLI call — XPC blocked by sandbox
$ obsidian files total
Connection Invalid error for service com.apple.hiservices-xpcservice
# (then hangs and gets terminated)

# Same command works perfectly in a regular terminal

Adding "obsidian" to excludedCommands does not help — it bypasses the filesystem sandbox but not the Mach port restrictions.

Related issue

Same root cause as #17042 (clipboard paste fails due to blocked com.apple.hiservices-xpcservice). That issue affects Claude Code's own clipboard feature; this issue affects user workflows that rely on CLI tools that communicate with running macOS apps — Obsidian, but potentially also Electron apps with CLIs, Raycast, Alfred, Shortcuts, etc.

Background: what we tried

When developing a Claude Code skill to use the Obsidian CLI, we systematically debugged the sandbox:

1. excludedCommands: ["obsidian"] — bypasses filesystem sandbox only, XPC still blocked
2. allowUnixSockets — the CLI uses Mach ports, not Unix sockets
3. allowAllUnixSockets: true — same result, wrong IPC mechanism
4. osascript -e 'do shell script "obsidian ..."' — this worked as a workaround because osascript ran outside the Seatbelt scope. We built the skill around this pattern (~Mar 1, 2026). As of v2.1.70, this no longer works either — StandardAdditions can no longer load (do shell script fails with syntax error -2740). This is actually the right fix from a security perspective — osascript + do shell script was a full sandbox escape. It shouldn't have worked.

The problem is: now there's no path to allow a trusted CLI tool to do IPC with its parent app.

Diagnostic evidence

# Basic osascript works (no IPC needed)
$ osascript -e 'return "hello"'
hello

# StandardAdditions blocked (do shell script = full sandbox escape, correctly blocked)
$ osascript -e 'do shell script "echo hi"'
0:8: syntax error: A identifier can't go after this identifier. (-2740)

# Obsidian CLI — XPC blocked
$ obsidian search query="test"
Connection Invalid error for service com.apple.hiservices-xpcservice

# Environment confirms sandbox
$ echo $SANDBOX_RUNTIME
1

What Should Happen?

excludedCommands should fully exclude a command from the sandbox, including Mach port / IPC restrictions. If a user has explicitly trusted a command by adding it to excludedCommands, it should be able to do everything it needs — filesystem access, network, and IPC.

The current behavior creates a confusing half-exclusion: the command can write anywhere on disk but can't talk to a running app on the same machine.

Alternatively, a more granular option could work:

{
  "sandbox": {
    "excludedCommands": ["obsidian"],
    "allowMachLookup": ["com.apple.hiservices-xpcservice"]
  }
}

But simply making excludedCommands a true exclusion would be simpler and match user expectations.

Cross-platform note

This is macOS-specific because Mach ports are a macOS IPC mechanism. It would be interesting to know how Obsidian's CLI communicates on Linux/Windows — if it uses a different IPC mechanism there, this may only need a macOS sandbox fix.

Claude Code Version

2.1.70 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Ghostty