---
name: agent-pane-stuck-typing-no-effect
description: "When an agent's tmux pane \"won't accept typing,\" the first thing to check is whether it's in tmux copy mode — one keystroke fix, not a FUSE problem"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: cd07777c-8add-4afc-9cb9-9113caa0331f
---

When Cameron reports an agent's pane is "stuck" and typing has no effect, **check `tmux display-message -p -t agents:<name> '#{pane_in_mode}'` FIRST**. If it returns `1`, the pane is in tmux copy mode — copy mode consumes every keystroke for scrolling/searching, so nothing reaches the underlying Claude TUI even though the TUI is healthy. One keystroke fixes it: `tmux send-keys -t agents:<name> q`.

**Why:** Easy to enter accidentally via stray scroll wheel, scrollbar drag, or `Ctrl-b [`. Diagnosed on yams on 2026-06-14. From symptom ("can't type") to fix took ~3 seconds with no mount touches.

**How to apply:**
- Always check pane mode before doing any heavier diagnostic.
- Safe parallel signal: `mode=1` + `alt=0` + Claude TUI rendered normally in the pane capture = copy mode, not a wedged process.
- If `mode=0` and typing still doesn't work, *then* move to procfs (`ps -o stat,wchan` — any `D` state = potential FUSE wedge; `Sl+` + `ep_pol` = healthy idle Claude).
- Avoid `ls`/`stat`/`df` on or near sshfs mountpoints during these diagnostics — they can wedge the diagnostician too. Pane capture + `/proc/<pid>/{status,wchan}` are both safe (no mount traversal). [[feedback_vault_references]] reminded me to stay surgical.