[BUG] macOS: Claude Code probes /home (autofs) and triggers a Network Volumes TCC prompt from a pre-warmed Desktop session; denied access retried on every Bash call

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?

On macOS, Claude Code (the claude binary launched by Claude Desktop) reads /home (/System/Volumes/Data/home, an autofs mount point). macOS treats autofs as a network volume, so this triggers a TCC "access files on a network volume" prompt for com.anthropic.claude-code, even though the user never asked Claude to touch a network volume.

What I observed:

1. Claude Desktop pre-warmed a session ([WarmLifecycle:session] Warming session …, session spawn … in main.log). No user message or tool call had been sent to that session.
2. About 2 s after the spawn, the new claude process hit a TCC prompt through sandboxd (logs below).
3. Before that, other claude processes had already been denied on the same path dozens of times over ~8 minutes, without a prompt. The denials lined up with Bash tool calls in an active session: each denial fell between the Bash tool_use and its tool_result. The denied result seems not to be cached, so it is retried on every call.
4. After I clicked Allow, no further denials were logged.

Granting the prompt gives Claude Code access to all network volumes (for example a mounted company SMB share), which is far broader than what this /home probe needs.

What Should Happen?

Claude Code should not touch /home on macOS in a way that requires the Network Volumes TCC permission. At minimum it should:

• not trigger the prompt from a background pre-warmed session with no user action, and
• cache a failed or denied result instead of retrying on every Bash call.

Error Messages/Logs

# macOS unified log (pid <P> = claude process spawned by Desktop pre-warm)
sandboxd: request approval
sandboxd: (TCC) tcc_send_request_authorization() IPC
tccd: AUTHREQ_ATTRIBUTION: accessing={identifier=com.anthropic.claude-code, pid=<P>, binary_path=…/claude-code/2.1.281/claude.app/Contents/MacOS/claude}, requesting={identifier=com.apple.sandboxd, binary_path=/usr/libexec/sandboxd}
tccd: AUTHREQ_PROMPTING: service=kTCCServiceSystemPolicyNetworkVolumes, subject=Sub:{com.anthropic.claude-code}Resp:{… pid=<P> …}
tccd: Publishing <TCCDEvent: type=Create, service=kTCCServiceSystemPolicyNetworkVolumes, identifier=com.anthropic.claude-code>   # user clicked Allow
kernel: [com.apple.sandbox.reporting:violation] 3 duplicate reports for System Policy: claude(<P>) deny(1) file-read-data /System/Volumes/Data/home

# earlier, other claude processes (pid <Q>, <R>) during Bash tool calls, no prompt shown
kernel: … System Policy: claude(<Q>) deny(1) file-read-data /System/Volumes/Data/home
kernel: … 7 duplicate reports for System Policy: claude(<Q>) deny(1) file-read-data /System/Volumes/Data/home
kernel: … System Policy: claude(<R>) deny(1) file-read-data /System/Volumes/Data/home

Steps to Reproduce

1. On macOS with the default /etc/auto_master (contains /home auto_home -nobrowse,hidefromfinder), make sure Claude Code has not been granted "Network Volumes" in System Settings → Privacy & Security → Files and Folders.
2. In Claude Desktop (Code tab), click a local session in the sidebar so the app pre-warms its CLI process (do not send a message). Alternatively, run any Bash tool call in an active local session.
3. Watch for the "would like to access files on a network volume" prompt, and run:

log show --last 1h --style compact --predicate 'eventMessage CONTAINS "System Policy: claude("'

1. Observe repeated deny(1) file-read-data /System/Volumes/Data/home entries for claude processes, and the TCC prompt attributed to com.anthropic.claude-code via sandboxd.

These steps describe what I observed on one machine. I have not re-run them as a controlled repro.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.281 (Claude Code bundled by Claude Desktop 2.9939.2, which reports itself as up to date). The standalone CLI latest is 2.1.283; not re-tested there, and the 2.1.282/2.1.283 release notes do not mention this (2.1.282 fixes a related /home symlink-listing case only).

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Likely cause (related: #77758)
#77758 showed with lldb that the CLI unconditionally open()s /home/claude/.claude/remote/.oauth_token at startup. The same constant is in the 2.1.281 bundle ("/home/claude/.claude/remote" with .oauth_token, .api_key, .session_ingress_token). On macOS, /home is an autofs mount point, so the lookup alone triggers the Network Volumes TCC check. #77758 was about a hang when automountd is wedged and was closed as stale. This report covers the TCC prompt and repeated denials that the same kind of probe causes in a normal environment.

The bundle also has /home-related logic that reads /etc/auto_master and otherwise stats /home (homeIsOwnMount), plus hard-coded path lists that include /home. I could not tie the denials during Bash execution to one specific call. This part is inferred from minified strings, not from a stack trace.

Suggested fix (as in #77758): decide remote/sandbox mode from a cheap signal such as an environment variable before touching /home/claude/..., and avoid probing /home on macOS.

Environment: Claude Desktop (Code tab) on macOS, Apple Silicon, permission mode auto, Bash sandbox enabled, an unrelated SMB share mounted under /Volumes/.

Impact: an unexpected security prompt appears with no user action. Users are likely to click Allow, which grants Claude Code broad access to network volumes (including company file shares).