[Bug] Session appears stuck when bash command disrupts network connectivity

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Bug Description

When a bash command disrupts the host's network connectivity (e.g., reloading a WiFi driver with modprobe -r brcmfmac && modprobe brcmfmac), the session appears stuck/hung. The command itself completes successfully on the host, but Claude Code cannot retrieve the tool output because the connection was interrupted.

Observed behavior:

1. User approves a bash command that disrupts network (e.g., WiFi driver reload, network interface restart)
2. The command executes and completes on the host
3. Claude Code shows no output and appears frozen — no spinner, no timeout, no error message
4. The user must manually interrupt (Escape key)
5. After interrupting, subsequent tool calls may also appear stuck until the user manually restores connectivity (e.g., reconnects to WiFi from the OS network menu)
6. Claude has no awareness that it was the bash command that caused the connectivity loss and may attempt similar commands again

Expected behavior:

• A timeout or connectivity-loss detection that surfaces an informative message like "Network connectivity lost — the previous command may have disrupted your connection"
• Or at minimum, the existing command timeout (2 minutes) should fire and return an error rather than hanging silently

Reproduction Steps

1. Use Claude Code on a laptop connected via WiFi (no ethernet)
2. Ask Claude to debug a WiFi driver issue
3. When Claude runs a command like sudo modprobe -r brcmfmac && modprobe brcmfmac, the WiFi driver unloads, dropping the connection
4. The session hangs with no feedback

Environment Info

• Platform: linux (Linux Mint 22.3, kernel 6.17.0-19-generic)
• Terminal: gnome-terminal
• Shell: bash
• Connection: WiFi only (MacBook Pro 14,1)

Additional Context

This came up during a hardware debugging session where WiFi driver reloads were frequent. The workaround is for the model to warn the user before running connectivity-disrupting commands, but ideally the tool infrastructure would detect the lost connection and report it gracefully.

Related issues: #33948, #29351