[BUG] Background session daemon enters infinite crash-respawn loop when session process is stuck in kernel D-state (dead FUSE mount)

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?

A background session's underlying process got stuck in kernel D-state (uninterruptible sleep, inside a statx() call on a dead sshfs/FUSE mount — the remote host had been torn down externally). Because the process was in D-state, it could not receive any signal (not even kill -9) and could not respond to the daemon's control socket.

The daemon did not detect this. Instead, it repeatedly tried to reclaim/respawn the same session ID in a tight loop (roughly every 10-20 seconds), crashing every time with the same generic message, for several minutes while consuming CPU. claude attach <id> and claude stop <id> both failed repeatedly with a message saying the session was "running as a background session," which was misleading — the process wasn't usably "running," it was unresponsive.

What Should Happen?

1. The daemon should detect when a background session process is unresponsive for an extended period (not answering the control socket) and give a clearer diagnostic (e.g. "session process appears stuck, possibly blocked on I/O") instead of the generic "run attach or stop" message.
2. The respawn loop should have backoff / a max-retry cap instead of retrying indefinitely on the same crash.
3. claude stop on a genuinely stuck process should report something more actionable than "couldn't confirm stopped — try again in a moment," since no amount of retrying helps without external intervention (in my case, force-unmounting the dead FUSE mount).

Error Messages/Logs

daemon.log excerpt:
\`\`\`
[09:05:11.579] bg settled 2bce2eeb (killed)
[09:05:11.640] bg claimed-spare 2bce2eeb (respawn)
[09:05:22.222] bg settled 2bce2eeb (killed)
[09:05:33.309] bg claimed-spare 2bce2eeb (fleet)
[09:05:55.288] bg settled 2bce2eeb (crashed): exit 1 ×3 — exit_with_message: Session 2bce2eeb-... is running as a background session (2bce2eeb). Run `claude attach 2bce2eeb` to open it, or `claude stop 2bce2eeb` first to resume it here. Add --fork-sessi
[09:06:04.855] bg claimed-spare 2bce2eeb (fleet)
[09:06:26.624] bg settled 2bce2eeb (crashed): [same message]
\`\`\`

/proc diagnosis of the stuck process:
\`\`\`
$ ps aux | grep 2bce2eeb
... D ... /home/.../claude --session-id 2bce2eeb-... --agent claude --inherit-permission-mode acceptEdits

$ sudo cat /proc/<pid>/stack
request_wait_answer
fuse_simple_request
fuse_do_getattr
fuse_update_get_attr
fuse_getattr
vfs_getattr_nosec
vfs_statx
do_statx
\`\`\`

Steps to Reproduce

1. Mount a remote filesystem via sshfs (with reconnect option) inside a background Claude Code session's working directory / an accessible path.
2. Run a command inside the session that does statx() on files under that mount (e.g. find traversing the mount).
3. Externally tear down the remote host so it becomes completely unreachable (DNS no longer resolves, SSH refuses connections) while the find is still in flight — e.g. an external job scheduler reclaiming the node.
4. The session process becomes stuck in kernel D-state, unkillable, unresponsive to the daemon's control socket.
5. Observe claude attach <session-id> / claude stop <session-id> failing repeatedly, and the daemon log showing a crash-respawn loop for that session ID.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

N/A

Claude Code Version

2.1.284

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

The D-state condition itself is not a Claude Code bug — it was caused by an external job scheduler tearing down a remote node while a find command was traversing an sshfs mount inside the session. The mount was a zombie (host no longer resolved via DNS, SSH refused connections) and reconnect never succeeded because the target no longer existed. Force-unmounting the dead mount (fusermount -uz) immediately resolved the D-state process, after which claude stop succeeded normally.

Filing this because the daemon's handling of the resulting stuck process — infinite crash-respawn loop, unhelpful diagnostics, no backoff — seems like a robustness gap worth addressing, since this kind of "remote mount dies mid-operation" scenario is common in setups where Claude Code sessions run against network/cluster filesystems.