[BUG] claude agents TUI fully unresponsive on Windows Terminal — broken rendering + dead input loop (2.1.143)
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?
Running claude agents (added in 2.1.139) on Windows Terminal results in two compounding failures that make the agent view completely unrecoverable without killing the terminal:
1. TUI elements render in wrong vertical positions.
On initial launch, the header (Claude Code v2.1.143 / Opus 4.7 (1M context) · C:\Pipeline / 0 awaiting input · 1 working · 0 completed) and session row render, but the composer input region is missing entirely — only the shortcut footer (enter to open · space to reply · ctrl+x to delete · ? for shortcuts) is present, sitting where the input should be. The "Type a task below to dispatch a session" hint text is shown, but there is no input to type into.
After a session state change (the /projects session transitioned from working to Needs input for a Bash approval), the layout shifted further: the footer moved to the top of the visible area, the header info appeared below it, and the session row landed sandwiched between misplaced header text — see attached screenshots.
2. Keyboard input is completely dead.
None of the following had any effect once the TUI was in its corrupted state:
Enter,Space,?(documented shortcuts in the footer)- Arrow keys (
→,←,↑,↓) Ctrl+CCtrl+Break- Mouse clicks on session rows
The only way to exit was closing the Windows Terminal tab/window entirely. The background /projects session was correctly recovered afterward via claude --resume.
What Should Happen?
- All TUI regions (header, session list, body hint, composer input, footer) render in their correct vertical positions on initial launch and persist across state changes.
- Documented keyboard shortcuts (
Enter,Space,→,Ctrl+C) reach the input handler. - At minimum,
Ctrl+Calways exits cleanly without requiring a terminal kill so users are never forced to kill the terminal window.
Error Messages/Logs
Steps to Reproduce
- Open Windows Terminal (default profile: Windows PowerShell 5.1)
- Have at least one existing claude session running in another worktree/directory (so agent view has a session to list)
- Run
claude agents - Observe: composer input region is missing on initial render — only header, session row, and footer present
- Wait for any session to change state (e.g. request a permission approval)
- Observe: TUI elements re-render in wrong vertical positions (footer moves to top, header moves to middle)
- Attempt to press any documented key (Enter, Space, arrow keys, ?) — observe nothing happens
- Attempt
Ctrl+C/Ctrl+Break— observe nothing happens - Resort to closing the Windows Terminal window via the X button; the background session can then be recovered via
claude --resume
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.143 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Environment details
- OS: Microsoft Windows 11 Pro 25H2 (build 26200.8457)
- Terminal: Windows Terminal 1.24.11321.0
- Shell: PowerShell 5.1.26100.8457 (Windows PowerShell, not PowerShell 7)
- Node: v26.1.0 / npm 11.8.0
Workarounds tried
- Resizing the Windows Terminal window — did not restore the input region. Made layout worse on second attempt (elements moved to new wrong positions instead of correct ones).
Ctrl+L— no effect (no keyboard input reaches the process at all).- Waiting for re-render after session state change — produced a different broken layout, did not restore functionality.
- Could not test
/tuifullscreen renderer since input was dead and/tuiis a slash command inside an attached session, not an agent view command.
Notes on shell
This was reproduced under Windows PowerShell 5.1 (the bundled, legacy shell), not PowerShell 7. The closely-related #58579 was filed against PowerShell 7.6.1 with similar rendering symptoms but did not report a wedged input loop, so the 5.1 vs 7.x distinction may be relevant for triage. Have not yet retested under pwsh (PowerShell 7) to determine whether the input-loop death is shell-specific or terminal-specific.
Severity rationale
This is a research preview feature, but the failure mode (unrecoverable wedge requiring terminal kill) is more severe than typical rendering issues — there is no in-app escape path. On Windows Terminal + Windows PowerShell (a common default Claude Code config on Windows), claude agents is currently unusable.
Related issues
- #58579 —
/agents view lines stack/overlap on Windows Terminal (2.1.140)— same area (area:agent-view,platform:windows) but different failure mode. #58579 reports row overlap on the same line; this report is about elements being placed at wrong vertical positions AND complete input event loop death. - #52410 — permission prompt render-loop on WT
- #19637 — long-standing Windows TUI overlap/garble since 2.1.3
- #16578 — status lines stacking instead of updating in place
Suggested labels
area:agent-view · area:tui · platform:windows · bug · has repro
Showing cached comments. Read the full discussion on GitHub ↗
6 Comments
Confirming this repros on PowerShell 7.6.1 as well — the trigger isn't legacy PowerShell 5.1.
Env:
~/.local/bin/claude.exe)My repro path is slightly different from the OP's: it happens after attaching to a session from agent view (
Enteror→), then detaching back to the table via←. The terminal is then unresponsive to every input includingCtrl+C/Ctrl+Z/Ctrl+Break. Only fix is killing the WT tab.Worked fine on 2.1.142. Downgrading with
claude install 2.1.142clears it for me — confirmed.Likely related: the 2.1.143 changelog claims to fix _"on Windows, pressing ← in
claude agentswhile a response was streaming could leave the agents list unresponsive to all input"_ — but the fix appears incomplete or introduced a regression on the detach path more generally. Also see #58579 (TUI overlap, same WT version).im noob so sorry if i dont do this correctly <3 blessings to all the engineers here!
Still reproing on 2.1.150 — bug has survived 7 releases since the original 2.1.143 report.
Env:
Symptom in my repro: input region renders but stacks/overlaps with the previous prompt's footer — multiple horizontal rule lines pile up on top of each other, the tab label (
test line check) and prior input text bleed through into the composer. Doesn't fully wedge input on my end (I could still type and submit), but the layout is unreadable. Screenshot attached.This matches the same
area:agent-view+platform:windowscluster as #58579 (closed) and #59901 (macOS scroll). Filing the regression confirmation since the fix flagged in 2.1.143's changelog clearly didn't fully land.<img width="1999" height="1194" alt="Image" src="https://github.com/user-attachments/assets/b5cd141d-2d03-447d-981e-918f5b24329b" />
and yeah when i resize the terminal it temporary is correct again but then it gets messed up again. over and over! good luck oh great devs!!!
Still reproducing on 2.1.158 — this bug has now survived ~15 releases since the original 2.1.143 report.
The
claude agentsview becomes input-dead: keyboard input stops reaching the handler, so the documentedctrl+x to deletefor completed sessions never fires and completed sessions can't be cleared. Only recovery is killing the terminal; the background session is recoverable afterward viaclaude --resume.Env:
For triage: the closely-related root causes appear already addressed — the
←-detach wedge (#59814) was fixed in 2.1.144, and the CPU-pressure input-loop starvation (#63504) was closed as "addressed by a merged fix." But the original launch-time render-corruption + dead-input wedge described here still persists on the latest version.This issue still only carries the auto-applied
buglabel. Suggested labels:platform:windows·area:tui·area:agent-view·has reproI still have the bug here in v2.1.161
Seeing same issue in v2.1.163.
Still seeing this in v2.1.197.