[BUG] CLI hangs indefinitely at startup: uninterruptible openat() on /home/claude/.claude/remote/.oauth_token when /home autofs is unresponsive (macOS)

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?

claude hangs forever at startup with a completely blank screen — no output, no TUI, no error. Ctrl+C / Ctrl+D have no effect; the process must be killed with kill -9 from another terminal. claude --debug hangs identically with zero log output. claude --version works fine.

The hang is fully deterministic: every launch, every terminal (Terminal.app and iTerm2), in any working directory including an empty one, and it persists after removing ~/.claude.json and ~/.claude entirely. Reproduced on 2.1.208 / 2.1.209 / 2.1.210 and

What Should Happen?

Startup should never block indefinitely on a filesystem probe. Suggested fixes, any of which would resolve this:

1. Check a cheap signal first (environment variable) to decide whether the CLI is in a remote/sandbox environment, instead of open()ing /home/claude/... unconditionally;
2. lstat()/detect that the path

Error Messages/Logs

No error output at all (that is part of the bug). Diagnostic evidence:

`sample` of the hung process — all 4322 samples over 5s on the same frame:


4322 Thread ... DispatchQueue_1: com.apple.main-thread (serial)
  + 4322 start (in dyld) + 6688
  ...
  + 4322 openat$NOCANCEL (in libsystem_kernel.dylib) + 76
  +   4322 __openat_nocancel (in libsystem_kernel.dylib) + 8


lldb breakpoint transcript (last probed path before the permanent hang):


(lldb) memory read -f s $x1
0x...: "/home/claude/.claude/remote/.oauth_token"
(lldb) continue
Process resuming    ← never stops again


`lsof` on the hung process confirms it has not yet opened `~/.claude.json` or any config — it dies earlier than all

Steps to Reproduce

Requires an environment where open() under /home blocks (a wedged automountd; encountered naturally on macOS 27 developer beta, and reproducible in principle with any hanging autofs/NFS map for /home):

1. On macOS with the default /etc/auto_master (/home auto_home line active), get automountd into a non-responsive state for /home lookups. Sanity check: ls /home/claude in a plain shell hangs uninterruptibly (this confirms the environmental precondition, independent of Claude Code).
2. Run claude.
3. Observe: blank screen forever, Ctrl+C dead, claude --debug prints nothing, process must be SIGKILLed.

Workaround that fully restores the CLI: comment out the /home line in /etc/auto_master, run sudo automount -vc, reboot. /home/claude then returns ENOENT instantly and claude starts normally.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.210 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

• OS: macOS 27.0 Developer Beta 3 (26A5378n), Apple Silicon. The underlying autofs/automountd wedge is an OS-level bug on this beta (even sudo automount -vc hangs while touching the mount point) and is being reported to Apple separately via Feedback Assistant. Claude Code's part is performing an unbounded synchronous probe against a path that can live on a network/autofs mount.
• Full sample reports and the complete lldb transcript (all probed paths) available on request; can attach.