[BUG] v2.1.137 macOS — Read/Bash on SMB-mounted volume returns EPERM without --add-dir, even with dangerouslyDisableSandbox=true

Summary

On macOS, Claude Code v2.1.137 returns Operation not permitted (EPERM) when accessing files on an SMB-mounted volume, even though:

• The user owns the mount (drwx------ pingu:staff)
• The SMB session is healthy (smbutil statshares shows SMB 3.1.1 with active encryption)
• The Bash tool's dangerouslyDisableSandbox: true flag is set
• The same volume worked across many sessions in earlier v2.1.x versions

The only known workaround is launching with --add-dir /Volumes/storage or adding permissions.additionalDirectories to settings.json. v2.1.133's release notes mention "Fixed Read/Write/Edit being denied on mapped network drives passed via --add-dir / SDK additionalDirectories", suggesting this sandbox enforcement has tightened, but this session was launched without --add-dir, matching the pattern of previously-working invocations.

Environment

• Claude Code: v2.1.137 (also reproduced via fresh launch on this version)
• Platform: macOS Darwin 25.4.0 (arm64)
• Mount: //pen@continent.local/storage on /Volumes/storage (smbfs, nodev, nosuid)
• User: matches mount owner (uid 501)
• Working dir at launch: /Users/pingu/.openclaw (NOT under /Volumes/storage)

Repro

1. Mount an SMB share at /Volumes/<name> (Finder or mount_smbfs)
2. Launch Claude Code without --add-dir: claude from a working directory NOT under that volume
3. From within Claude Code, attempt any of:

• Read tool on a file under /Volumes/<name>/...
• Bash tool ls /Volumes/<name>/some-dir/
• Bash tool cat /Volumes/<name>/some-file
• Same Bash with dangerouslyDisableSandbox: true

1. All return Operation not permitted

Expected

Either:

• (A) Read/Bash on user-owned mounted volumes works without --add-dir, matching prior-version behavior, or
• (B) The error message clearly states the path requires --add-dir / additionalDirectories so users can self-diagnose, or
• (C) dangerouslyDisableSandbox: true actually disables this sandbox layer for the Bash tool

Actual

Operation not permitted with no hint that the path needs to be added via --add-dir. Users have to dig into release notes (v2.1.133 line item) and unrelated issues (#30064, #52934) to learn that mapped network drives need explicit declaration.

Diagnostic data

$ mount | grep storage
//pen@continent.local/storage on /Volumes/storage (smbfs, nodev, nosuid, mounted by pingu)

$ stat -f '%Sp %Su:%Sg' /Volumes/storage
drwx------ pingu:staff

$ id
uid=501(pingu) gid=20(staff) groups=20,12,61,79,80,81,...

$ ls /Volumes/storage 2>&1
ls: /Volumes/storage: Operation not permitted

$ smbutil statshares -m /Volumes/storage | head -5
SHARE                         ATTRIBUTE TYPE                VALUE
storage
                              SERVER_NAME                   continent.local
                              USER_ID                       501
                              SMB_VERSION                   SMB_3.1.1

# entitlements identical to v2.1.131 (which used to work):
$ codesign -d --entitlements - .../versions/2.1.137 | head
Executable=.../versions/2.1.137
[Dict]
    [Key] com.apple.security.cs.allow-jit
    [Value] [Bool] true
    [Key] com.apple.security.cs.allow-unsigned-executable-memory
    ...

# parent process: plain zsh, no sandbox-exec wrapper
$ ps -o pid,ppid,command -p $$
  PID  PPID COMMAND
 8408  3985 claude

Workarounds confirmed

# One-shot:
claude --add-dir /Volumes/storage

# Permanent (~/.claude/settings.json):
{
  "permissions": {
    "additionalDirectories": ["/Volumes/storage"]
  }
}

Both unblock Read/Bash on the volume.

Suggested fix priority

Two related improvements would help:

1. Error message — surface "path is outside working directories; use --add-dir or permissions.additionalDirectories" when EPERM hits a path outside the allowed set, so users don't have to guess the cause.
2. dangerouslyDisableSandbox semantics — document whether this flag is intended to bypass the directory-allowlist check too, or only the per-command sandbox-exec wrapper. Current behavior (still EPERM on disallowed paths) was unexpected given the flag name.

Possibly related: #30064, #52934 (both about additionalDirectories vs --add-dir divergence).