[BUG] Ancestor-directory probes (CLAUDE.md, AGENTS.md, .mcp.json, .claude, .git) trigger multi-minute autofs NFS mount attempts; VS Code extension fails with 60 s init timeout (2.1.278)

Preflight Checklist

• [x] I have searched existing issues. The same root cause was reported in #82632 (July 2026), which was auto-closed as stale on 2026-09-07 without a fix; its closing comment asks to open a new issue if still relevant. It is, and 2.1.278 made it worse (details below).
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code (2.1.278).

What's Wrong?

On Linux hosts where a parent of the working directory is an autofs indirect map with a wildcard entry (common on HPC clusters, e.g. /g mapping * to &:/vol/&), Claude Code's startup walk over ancestor directories stats candidate file names in the autofs root. autofs treats each name as a mount key and spawns mount.nfs <name>:/vol/<name>. The statx() blocks in uninterruptible sleep (D state) until that mount attempt fails, which takes 23 s to more than 2 minutes per name.

Names probed directly under the autofs root in one start of 2.1.278 (from strace -f, cwd /g/stegle/aivazidis):

| path | probes per start |
|---|---|
| /g/.git | 4 |
| /g/AGENTS.md | 3 |
| /g/.mcp.json | 2 |
| /g/.claude | 2 |
| /g/CLAUDE.md | 1 |
| /g/CLAUDE.local.md | 1 |

The probes run sequentially on the main thread, so a cold start takes from ~25 s to several minutes. Because .md is a real TLD, claude.md resolves to Anthropic's own infrastructure (2607:6bc0::10) and agents.md to a third party (64.239.109.1), so the automounter genuinely sends NFS/portmapper RPC traffic to those hosts and waits out the full RPC retry ladder.

What is new in 2.1.278: the AGENTS.md discovery adds another probed name, and the VS Code extension has a hard-coded 60 s subprocess init timeout (Subprocess initialization did not complete within ${Q}ms, Q=60000 in extension.js). The combination turns a slow start into a hard failure:

Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity

That message is misleading: authentication and network are fine (verified: OAuth token valid, all Anthropic endpoints answer in <0.4 s). Several sessions launched close together all block on the same in-flight mount attempt and fail together. Log counts on my machine: 33 such timeouts on 2026-09-20, 18 on 2026-09-21, none before the extension auto-updated to 2.1.278 on 2026-09-19. A launch made within autofs's ~60 s negative-cache window after a failed attempt starts in ~1 s, which is why it looks intermittent.

Side effect worth noting: a root-owned mount.nfs stays in D state on a shared login node for every probe, and other users' processes touching the same key block behind it.

What Should Happen?

Startup should take seconds regardless of whether an ancestor is an autofs mount. Suggested fixes (any one would do):

1. Stop the ancestor walk at filesystem / mount boundaries, at least for fstype=autofs entries in /proc/self/mountinfo. Nobody keeps a CLAUDE.md or AGENTS.md in an automounter root.
2. Use readdir of the ancestor instead of blind stat of candidate names. Listing an autofs indirect root does not trigger key mounts; stat of a nonexistent name does.
3. Probe candidate names concurrently with a short deadline instead of sequentially without one.
4. Independently: make the extension's 60 s init timeout configurable, and don't attribute a generic init timeout to authentication/network in the error text.

Error Messages/Logs

strace -f -tt -T of claude -p "ok" in /g/stegle/aivazidis (only the relevant lines):

10:33:02.557290 statx(AT_FDCWD, "/g/CLAUDE.md", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, ...) = -1 ENOENT (No such file or directory) <23.039426>
10:33:25.613999 statx(AT_FDCWD, "/g/stegle/CLAUDE.md", ...) = -1 ENOENT <0.000...>
10:33:25.618159 statx(AT_FDCWD, "/g/AGENTS.md", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL,  <unfinished ...>
10:33:48.936928 <... statx resumed> ) = -1 ENOENT (No such file or directory) <23.318672>

Process state while blocked (ps), plus the automounter's child:

   PID STAT ELAPSED NLWP CMD
2598613 Dl     00:45   12 .../native-binary/claude -p ...          # main thread in statx (syscall 332)
2599306 D      02:11       /sbin/mount.nfs AGENTS.md:/vol/AGENTS.md /g/AGENTS.md -s -o rw,nosuid,nodev,rsize=1048576,wsize=1048576

Extension log (Claude VSCode.log): the subprocess prints [STARTUP] setup() completed in 114ms and mTLS: Creating HTTPS agent with custom certificates, then nothing until:

[error] Error spawning Claude (on channel aq10udbixu): Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity

/proc/mounts entry for the autofs root:

auto.in.g /g autofs rw,relatime,fd=30,pgrp=3639,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=93233 0 0

Steps to Reproduce

1. Linux host with autofs 5.x and an indirect map containing a wildcard, e.g. /etc/auto.master: /g /etc/auto.g, and /etc/auto.g: * &:/vol/& (any wildcard or program map reproduces it, including the stock /net -hosts).
2. cd /g/<some-real-share>/project
3. claude -p "ok" (or launch the VS Code extension with that folder as workspace).
4. In another shell: ps -eo stat,etime,cmd | grep mount.nfs shows mount.nfs CLAUDE.md:/vol/CLAUDE.md ... / AGENTS.md:... in D state; strace -f -T -e statx on the claude process shows the multi-second statx("/g/CLAUDE.md") / statx("/g/AGENTS.md").
5. Repeat within 60 s: fast (negative cache). Wait a few minutes: slow again.

Claude Model

N/A (startup, before any model call)

Is this a regression?

Yes, partially. The slow start existed before (#82632). The hard failure in the VS Code extension started with 2.1.278 (auto-installed 2026-09-19; timeouts began 2026-09-20). Last working version: whatever preceded 2.1.278 in the VS Code extension channel.

Claude Code Version

2.1.278 (VS Code extension anthropic.claude-code-2.1.278-linux-x64, Remote-SSH; the bundled native binary reports 2.1.278 (Claude Code))

Platform / OS / Terminal

Linux, Rocky Linux 8.10, kernel 4.18.0-553.144.1.el8_10.x86_64, autofs-5.1.4-114.el8_10.8, nfs-utils-2.3.3-69; VS Code Remote-SSH to an HPC login node, bash.