Cursor CLI: fresh agent session freezes keyboard on native Windows terminal after redraw; agent resume, IDE, and WSL work

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Summary

Starting a new interactive Cursor CLI agent session on native Windows (Command Prompt, PowerShell, or Windows Terminal) causes the terminal UI to stop accepting keyboard input shortly after launch. The problem does not occur when using agent resume, the Cursor IDE, or running from WSL.

Environment

• CLI version: v2026.05.07-42ddaca (and current install at time of report)
• OS: Microsoft Windows 11 Enterprise 10.0.26200 2009 26100.1.amd64fre.ge_release.240331-1435
• Terminals tested: Windows Terminal, Command Prompt, PowerShell (native Windows — not WSL)
• Windows Terminal “interaction” settings (copyOnSelect, copyFormatting, snapToGridOnResize, focusFollowMouse) were already set to recommended defaults — ruled out as cause.

Actual behavior

• Input works initially.
• After a short time, the terminal updates (prior scrollback / text appears cleared or redrawn).
• After that, the CLI no longer responds to keyboard input.
• Escape does not restore input.

What works (same machine / account)

• agent resume — CLI remains usable.
• Cursor IDE — agent usage works.
• WSL — CLI/agent usage works.

Impact

Cannot rely on the Cursor CLI for new agent sessions on native Windows; must use resume, IDE, or WSL as workarounds.

Notes for investigation

• Suggests a regression or bug in the first-run / new-session interactive path vs resume, specifically on native Windows consoles (possibly PTY / ConPTY / full-screen TUI redraw / stdin handling).
• Please advise if there is a supported non-TUI or diagnostic mode for new sessions to help narrow the failure.

Steps to Reproduce

  1. Open Windows Terminal (or standalone cmd.exe / PowerShell).
  2. Run the Cursor CLI to start a new agent session (e.g. cursor agent / equivalent entrypoint — not resume).
  3. Interact briefly; wait a few seconds.

Expected Behavior

The CLI should remain interactive: keyboard input should continue to work after any redraw or streaming UI update.

Operating System

Windows 10/11

Version Information

CLI Version 2026.05.07-42ddaca
Model Composer 2
Subscription Tier Enterprise
OS win32 (x64)
Terminal windows-terminal
Shell cmd

For AI issues: which model did you use?

Model Composer 2

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

This is a known bug with the CLI on native Windows. The issue is in how the CLI handles keyboard input during certain transitions (like the workspace trust dialog that runs at the start of a new session). A fix exists but hasn’t been merged into a release yet, which is why your CLI version still hits it.

Your workarounds are exactly right: agent resume, the IDE, and WSL all bypass the affected code path.

This should be resolved in an upcoming CLI update. I don’t have a specific timeline, but the fix is identified and pending release.

8

Thanks Mohit. It just suddenly started for me at the end of last week. Hopefully it’ll get fixed with that MR.