[BUG] Regression in 2.1.207: automount -hosts check forces a permission prompt on every Read inside the working directory when $HOME is under /net/<host>/ (autofs)

Bug Description

On systems where the user's home directory lives under an autofs -hosts mount (/net/<hostname>/... — common on shared dev servers), Claude Code's automount defense-in-depth check fires for every file access, including files inside the session's own working directory. Reads that the docs say require no approval ("Read-only … No, within the working directory") prompt on every call in interactive mode and are hard-denied in headless (-p) mode.

Two compounding problems:

1. The check is over-broad. It flags /net/<host>/ paths even when the path is already mounted (so no DNS lookup or new NFS mount can be triggered) and even when it is the session's own cwd and $HOME. In this configuration, every read the agent ever does prompts — allow rules like Read(//net/dev-server-abc/share/code/**) in ~/.claude/settings.json don't help, because the check runs outside the permission-rules system.
2. The interactive prompt hides the reason. The interactive dialog shows a bare "Read file … Do you want to proceed?" with no explanation. The actual reason only surfaces in headless mode ("Denied (would trigger DNS lookup and NFS mount to remote host)"). We spent a long debugging session auditing allow rules, hooks, managed settings, and workspace trust before discovering the real cause via claude -p.

Environment

• Claude Code v2.1.207 (native install), Linux (RHEL 8.10)
• $HOME=/net/dev-server-xyz/share — autofs -hosts map over the machine's own local disk:

``
$ mount | grep dev-server-xyz
/dev/sda2 on /net/dev-server-xyz/share type xfs (rw,relatime,...)
-hosts on /net/dev-server-xyz/share type autofs (rw,relatime,...)
``

• Permission mode: default. No ask/deny rules for Read, no PreToolUse hooks, no managed settings (remote-settings.json is {}), workspace trust accepted (hasTrustDialogAccepted: true).

Regression

Introduced in v2.1.207 (released 2026-07-10). Verified by downloading npm tarballs and grepping cli.js for the check string: absent in 2.1.147, 2.1.166, 2.1.185, 2.1.197, 2.1.200, 2.1.202, 2.1.204, and 2.1.206; present in 2.1.207+. Last working version: 2.1.206.

Steps to Reproduce

cd /net/<hostname>/<export>/some-project   # any project under an autofs -hosts path
claude -p "Use the Read tool to read line 1 of README.md"

Expected Behavior

README.md is inside the session's working directory, on an already-mounted filesystem, so the read should be auto-allowed per the documented behavior for read-only tools within the working directory. At minimum, an already-mounted /net path — or one matching an explicit Read(//net/...) allow rule — should not prompt on every single read.

Actual Behavior

Headless mode:

- **Read**: Denied (would trigger DNS lookup and NFS mount to remote host)

Interactive mode prompts on every read, with no stated reason:

Read file
  Read(/net/dev-server-xyz/share/code/yugabyte-db/README.md · lines 1-1)
Do you want to proceed?
❯ 1. Yes
  2. Yes, during this session
  3. No

--debug shows only executePermissionRequestHooks called for tool: Read before the prompt — nothing indicating the automount check. The relevant strings in the binary are Automount -hosts path detected (defense-in-depth check) / Automount -hosts glob pattern detected (defense-in-depth check).

Suggested Fixes

1. Skip (or auto-allow) the check when the target path is under an already-mounted filesystem — e.g. the resolved path is on the same mount as the session cwd or $HOME, so no new DNS/mount side effect is possible.
2. Failing that, let an explicit user-level Read(//net/<host>/...) allow rule satisfy the check for that host prefix.
3. Independently: show the reason in the interactive permission dialog (like headless mode does), so users can tell this apart from a permission-rule mismatch.

Workaround

If the same directory is reachable without the /net prefix (here /share is the identical inode), starting the session from that spelling avoids the check entirely:

cd /share/code/yugabyte-db && claude

A PreToolUse hook returning permissionDecision: "allow" (scoped to the known-local /net/<host>/ prefix, matcher Read|Glob|Grep) also overrides the check — verified on v2.1.207. So hooks can bypass this check even though allow rules can't, which may itself be worth a look.

Related (but distinct) issues

• #25137, #40076 — absolute-path allow rules not matching outside cwd (different mechanism; this bug fires inside cwd)
• #31032 — inconsistent glob matching (this check may explain some "inconsistent" reports on autofs systems)