[BUG] Win11: agent view daemon causes rendering stutter, invisible cursor, and orphan claude.exe processes in 2.1.169+
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?
On Windows 11 with the OS default terminal wrap (Start menu → pwsh.exe shortcut → Win11 ConPTY → Windows Terminal/modern conhost), Claude Code 2.1.169+ exhibits three correlated regressions:
- Cursor disappears in the input prompt (no visible caret). Happens in the WT-detected code path (
WT_SESSIONenv var set) and in the classic main-screen renderer (tui: "default"). Cursor is visible only in the fullscreen renderer withWT_SESSIONempty.
- Choppy/stuttering rendering of streaming tokens and the "cooking" counter color animation. Token streaming visibly batches/stutters instead of flowing smoothly as in 2.1.153.
- Orphan
claude.exeprocesses accumulate in the background across sessions. After several CC starts and exits, Task Manager shows multiple lingeringclaude.exeprocesses. Deleting the installation directory fails with "Access denied" until all are killed manually.
Consistent visual symptom on every startup since the regression: two brief console windows flash on screen and disappear immediately before the CC TUI renders. This is the agent view daemon spawning child Node processes.
Setting "disableAgentView": true in ~/.claude/settings.json fully resolves all three issues. Other render-related settings (tui, prefersReducedMotion, showThinkingSummaries, terminalProgressBarEnabled) do not help.
What Should Happen?
CC should launch directly into a fresh REPL session with:
- No flashing console windows on startup
- Smooth token streaming matching 2.1.153 behavior
- Visible input cursor in all renderer paths and terminal launch modes
- Clean process exit — no orphan
claude.exeprocesses left running after/exit
The agent view feature is useful, but its on-demand daemon should not degrade interactive REPL performance for users who don't actively use background sessions. Consider lazy-spawning the daemon only when an agent view command is first invoked.
Error Messages/Logs
N/A — visual/rendering regression with no error log output.
No exceptions thrown, no stderr output.
The bug manifests as UX degradation (stutter, invisible cursor,
orphan processes) rather than functional errors.
Steps to Reproduce
- On Windows 11 Pro (build 26200), install Claude Code 2.1.153 globally via npm:
``powershell``
npm install -g @anthropic-ai/claude-code@2.1.153
- Launch PowerShell 7.6.2 from the Start menu shortcut (this routes through Win11's default terminal app via ConPTY —
WT_SESSIONenv var will be empty).
- Run
claude, send any prompt. Observe: smooth token streaming, visible cursor, no flashing windows, no orphan processes after/exit.
- Upgrade to 2.1.173:
``powershell``
npm install -g @anthropic-ai/claude-code@latest
- Launch the same way. Observe:
- Two console windows flash briefly on startup
- Dashboard view (agent view with completed/active sessions) appears instead of a fresh REPL
- Token streaming stutters; "cooking" counter color animation is choppy
- After
/exit,Get-Process claudeshows lingering processes
- Add to
~/.claude/settings.json:
``json``
"disableAgentView": true
- Launch CC again. Observe: fresh REPL straight away, no flashing windows, smooth streaming, no orphan processes after exit.
Renderer matrix observed during debugging
| CC version | Launch method | tui | WT_SESSION | Cursor | Stutter |
|---|---|---|---|---|---|
| 2.1.153 | Start menu pwsh (implicit ConPTY wrap) | fullscreen | empty | visible | smooth |
| 2.1.153 | wt.exe pwsh -NoExit -Command claude (explicit WT) | fullscreen | set | invisible | stutters |
| 2.1.173 | Start menu pwsh (implicit wrap) | fullscreen | empty | visible | stutters |
| 2.1.173 | Start menu pwsh (implicit wrap) | default (main-screen) | empty | invisible | stutters |
| 2.1.173 | wt.exe pwsh -NoExit -Command claude (explicit WT) | fullscreen | set | invisible | stutters |
| 2.1.173 + disableAgentView:true | Start menu pwsh (implicit wrap) | fullscreen | empty | visible | smooth |
Settings tested that did NOT help
All these were tried individually and in combinations:
tui: "default"— switched cursor bug from fullscreen path to main-screen path (net worse)prefersReducedMotion: true— killed "cooking" counter animation but didn't help stuttershowThinkingSummaries: false— slightly smoother but only marginalterminalProgressBarEnabled: false— no perceptible changeshowTurnDuration: false— no perceptible changeremoteControlAtStartup: false— no perceptible change- Switching to explicit
wt.exe pwsh.exe ...launch — made it strictly worse
Only disableAgentView: true resolved all three symptoms.
Hypothesized root cause
The agent view on-demand daemon spawns child Node processes on Windows that briefly flash conhost windows (visible as "two flashing windows"). The daemon then runs IPC/polling traffic that competes with token streaming render slots in the wrapped console pipeline, and does not clean up child processes on parent CC exit — resulting in process pile-up.
Suggested investigation
- Lazy-spawn the agent view daemon only when first agent-view command is invoked, not at every CC startup.
- Spawn daemon with
windowsHide: true+detached: trueinchild_process.spawnto avoid visible conhost flash. - Register daemon cleanup on parent CC exit (
process.on('exit')or Windows equivalent). - Investigate cursor management (
\e[?25l/\e[?25hpairing) in the WT-detected code path (WT_SESSIONset) — appears unmatched somewhere in the agent view startup sequence. - Separate cursor bug in
tui: "default"main-screen renderer — also reproducible.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.153
Claude Code Version
2.1.173 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Environment details
- OS: Windows 11 Pro, build 10.0.26200
- Shell: PowerShell 7.6.2 (
pwsh.exe) launched from Start menu shortcut - Terminal wrap: Win11 default terminal application —
DelegationConsole/DelegationTerminalregistry values ={00000000-0000-0000-0000-000000000000}(= "Let Windows decide" — wraps via ConPTY into Windows Terminal 1.24.11321 or modern conhost).WT_SESSIONenv var is empty in this wrap mode, set when launched explicitly viawt.exe. - PSReadLine: 2.4.5
- Console output mode:
0x7(ENABLE_PROCESSED_OUTPUT|ENABLE_WRAP_AT_EOL_OUTPUT|ENABLE_VIRTUAL_TERMINAL_PROCESSING) — VT processing enabled - Last known good CC version: 2.1.153 (smooth, cursor visible, no orphan processes, no flashing windows on startup)
- First reported broken: ~2.1.170
- Tested and confirmed broken: 2.1.173
- Hardware: High-spec desktop (not a perf bottleneck — 2.1.153 runs flawlessly in identical setup)
Why this matters
Windows is a primary platform target. The default Win11 launch path (Start menu PowerShell shortcut → pwsh.exe wrapped by ConPTY) is the most common setup for Windows users — and that's exactly the path where this regression hits. Users who don't know about disableAgentView will perceive CC as "broken after upgrade" and downgrade.
Workaround for affected users
Add to ~/.claude/settings.json:
{
"disableAgentView": true
}
Tradeoff: loses claude agents dashboard, --bg, /background, and the on-demand daemon. For pure interactive use, this is a no-op.
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate, but related to the linked issues.
Cross-referenced #66398 and #66441 — both are about cursor invisibility scoped to explicit agent view interaction (attach via
claude agentsin #66398, return navigation via/bgin #66441). #60782 is about a different setup (CJK + Git Bash + flicker).This issue is broader:
claude agents, no--bg, no/background). The on-demand daemon spawns regardless.claude.exeprocesses accumulating across sessions (not in any linked issue)WT_SESSIONset vs.tui: "default"), not just one"disableAgentView": trueresolves all three symptoms by skipping the daemon spawn entirelyThese likely share root cause family (the agent view daemon infrastructure introduced ~2.1.170) but the symptoms and triggers are distinct enough that consolidating would lose the broader picture. Happy to merge if maintainers prefer — but suggesting keep open for the additional symptoms and the working fix.
Retested on a clean 2.1.178 (Win11, isolated
CLAUDE_CONFIG_DIRso my main sessions weren't touched).Fixed:
claudestart creates nodaemon/dir and no extra processes. This matches thedocumented lazy behavior ("supervisor starts the first time you background a session or open agent view"), so the original "daemon spawns regardless on every startup" symptom appears
resolved.
Still broken — two distinct symptoms when using agent view on Win11:
claude agents→ dispatch a task → status shows1 working · opening… · 0sand hangs there forever, Enter doesn't register, then the sessionvanishes with:
> Couldn't reach the background service (not running) — run 'claude daemon status'
claude daemon statusreports:not running
control.sock: unreachable (connect ENOENT \.\pipe\cc-daemon-<id>-control)
roster.json: absent
daemon.log: absent
daemon.log: absentis the key signal — the supervisor crashes during boot before it can write a single log line. The only thing written to the daemon dir ispipe.key(16 bytes).Orphaned job state is left in
jobs/, though no orphan processes this time (it dies too early to spawn child workers).opening… 0shang, before getting into any session), the UIstutters/judders heavily. So the original render-performance symptom is not fixed — it now surfaces in the agent view UI itself, independent of the daemon crash.
So there are two separate problems here: the supervisor won't boot, and the agent view UI still renders with the same stutter reported originally.
Environment: Windows 11 Pro 26200, PowerShell 7, Windows Terminal, Claude Code 2.1.178.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.