[BUG] CLAUDE.md parent-directory search triggers ~3-minute NFS mount attempts against claude.md (Anthropic's own domain) on hosts with autofs wildcard/program maps

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 Linux hosts using autofs with a wildcard or executable (program) map — e.g. the stock /net -hosts entry, or an executable /etc/auto.nfs map that runs showmount -e "$key" — launching claude from a project directory located under the automounted path causes a consistent ~3 minute 15 second hang on every cold start. Subsequent runs are fast (2–8 s) for a few minutes, then it goes slow again.

Root cause: Claude Code walks up the directory tree from the cwd probing for CLAUDE.md, CLAUDE.local.md, .claude/, etc. at every ancestor level. When the cwd is under an autofs mount (e.g. /nfs/senna/scratch/.../project), the walk stats /nfs/CLAUDE.md. autofs treats CLAUDE.md as a mount key and tries to resolve it as an NFS server. Because .md is the Moldova TLD and claude.md is a real domain owned by Anthropic (resolving to 160.79.104.10 — the same IP as api.anthropic.com), the automounter genuinely contacts Anthropic's API infrastructure on the SunRPC/portmapper port trying to enumerate NFS exports. Anthropic's servers don't answer portmapper, so the RPC layer walks its full retry ladder (~2–3 min), once per probed filename. The claude process sits in uninterruptible sleep (D state, wchan autofs_mount_wait) the entire time. autofs then negative-caches the failed keys for a few minutes — which is why runs are fast immediately afterwards and slow again after idle.

Net effect: affected machines repeatedly send NFS mount requests to Anthropic's own API servers, and users see multi-minute startup hangs that look like (and were initially misdiagnosed as) network/firewall problems.

What Should Happen?

claude should start in seconds regardless of whether the cwd is under an autofs-managed path. The CLAUDE.md ancestor search should not trigger automount key lookups — e.g. by stopping the walk at filesystem/mount boundaries (autofs mounts are identifiable via /proc/self/mountinfo, fstype=autofs), by using readdir of the ancestor instead of blind stat of candidate names (readdir of an autofs indirect mount root does not trigger key mounts; stat of a nonexistent name does), or by bounding the probe with a non-blocking check/internal timeout so a hung stat can't block startup for minutes.

Error Messages/Logs

No error is shown — startup simply hangs, then completes normally.

Timing (identical for all models; it's the first invocation that's slow):

$ /usr/bin/time -f "Elapsed: %E" claude -p "say ok"
Ok.
Elapsed: 3:16.93

claude --debug shows the API leg itself is healthy inside a 3:17 wall-clock run:

[log_db7862, request-id: "req_011CdWUVxDp7FoXtCcmQdQ5p"] post https://api.anthropic.com/v1/messages?beta=true succeeded with status 200 in 5523ms

Blocked process during the stall:

$ ps -o pid,wchan:30,cmd -C claude
    PID WCHAN                          CMD
2945684 autofs_mount_wait              claude -p say ok

Smoking gun — the automounter's child process during the stall:

$ ps aux | grep showmount
root  2946164  ...  /sbin/showmount --no-headers -e CLAUDE.md

tcpdump during a cold run (filtered to 160.79.104.10) shows SunRPC/portmapper retries to Anthropic's API IP for the duration of the hang, with the HTTPS response completing only after RPC gives up:

shelby.947 > 160.79.104.10.sunrpc: Flags [S], seq 3709983126, ...   (TCP SYN retries)
shelby.947 > 160.79.104.10.sunrpc: UDP, length 92                   (repeats every 15s)
...RPC exhausts -> burst of remaining HTTPS packets, run completes

strace of a cold run shows a healthy TLS session to api.anthropic.com whose response body stalls ~190 s (while the process is in the mount wait) then arrives in one burst. Full strace, pcap, and debug log available on request.

Steps to Reproduce

1. Linux host with autofs enabled and an indirect map that treats keys as NFS hosts — either the stock /net -hosts in /etc/auto.master, or a program map like the widely-copied executable /etc/auto.nfs that runs showmount -e "$key".
2. Ensure public DNS resolution works (so hostname CLAUDE.md resolves via domain claude.md → 160.79.104.10).
3. cd into a project directory under the automounted mount point, e.g. /nfs/<server>/<export>/some/project.
4. Run claude -p "say ok" and time it → multi-minute hang.
5. During the hang: ps aux | grep showmount shows autofs attempting to resolve CLAUDE.md as an NFS server; ps -o pid,wchan,cmd -C claude shows autofs_mount_wait.
6. Mechanism reproduces without Claude Code at all: time ls /nfs/CLAUDE.md (or /net/claude.md) blocks for the full RPC retry duration before returning ENOENT.

Note: runs are fast for a few minutes after a slow run (autofs negative cache), so allow ~5 min idle between cold tests.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Xterm

Additional Information

• Consistency of the delay (3:14–3:17 across many runs) is the deterministic sum of NFS/RPC retransmission schedules across the several probe filenames checked at the automount root.
• Machines without autofs (Windows laptops, same account/network) are always fast — the issue is per-machine, not network-side.
• Confirmed user-side workarounds: allowlist real server names (or reject dotted keys) in the program map, wrap showmount in timeout 2, and/or comment out /net -hosts if unused. With those in place, cold start drops from ~3:15 to normal single-digit seconds.
• The collision only "works" because Anthropic owns claude.md — any environment combining the CLAUDE.md ancestor walk with hostname-style automount maps will end up sending NFS mount traffic to Anthropic's own servers.