Agents Window chat silent / stuck Planning — Design Mode Ctrl+L broken

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Title

Agents Window chat stays silent / stuck on “Planning next moves” while Design Mode works; Ctrl+L messages do not reach a responding agent (classic Dual chat works)

Environment

Cursor version: 3.13.25 (x64) — 31e8d61c448c7472e371505838a0fe34083dad50

OS: Windows 10 / 11 (build 26200)

Layout: DANA2 Dual workspace (classic IDE) + Agents Window

Local app: Next.js on localhost port 3001 (and :3000)

What works

Chat in the classic / Dual editor sidebar responds normally.

Design Mode can be enabled (blue Design control) in Agents Window browser; element select / draw works visually.

Select Element in Simple Browser can attach DOM context when used with the working Dual chat.

What fails

Agents Window agent chats do not answer

New or existing Agents Window chats accept send (message appears in the transcript).

No assistant reply for minutes.

UI often stuck on “Planning next moves”.

Example: chat titled roughly “Tudunk itt magyarul csevegni?” — user sent Hungarian + “hello” / “szia”; no response.

Same named chat split across surfaces

“Live view collaboration setup” shows messages as sent in Agents Window.

The agent instance that actually answers only receives messages when they are sent on the Dual/classic path.

User must copy-paste Agents Window messages into Dual chat to get any reply. This breaks Design Mode workflow.

Design Mode + Ctrl+L cannot target a working responder

Ctrl+L adds context to the active Agents chat (no destination picker).

If that chat is the silent one, the selection never gets an agent reply.

Design Mode overlay (“Describe the change…”) therefore feels dead even though Design UI is on.

Steps to reproduce

Open Cursor with a multi-root / dual workspace; keep a working classic Agent chat.

Open Agents Window (top-right control).

Start a New Agent chat (or open an Agents Window chat) and send a short message (e.g. “hello”).

Observe: message appears; status Planning next moves or idle; no reply.

Separately: Agents Window → File → New Browser → localhost port 3001 → enable Design Mode.

Select an element / draw → Ctrl+L → type a change request in that Agents chat.

Observe: request sits in Agents transcript; no agent action. Same text pasted into classic Dual chat does get a reply.

Expected

Agents Window chats should stream replies like classic Agent chat.

Design Mode selections (Ctrl+L) should land in a chat that actually runs the agent, or allow choosing the destination chat.

“Planning next moves” should not hang indefinitely without output.

Actual

Agents Window: send succeeds visually; agent silent / stuck planning.

Design Mode usable for selection only; end-to-end “point → agent edits” broken because the chat side is dead.

Classic Dual chat remains the only reliable channel.

Impact

Blocks the intended Design Mode workflow for UI work. Forces painful copy-paste between Agents Window and Dual chat. Design Mode is critical for this project; current split makes it unusable in practice.

Request IDs

Please add after copy from the silent Agents Window chat:
… menu on the chat → Copy Request ID

(Privacy: if needed, temporarily enable Share Data, reproduce once, copy Request ID, then restore Privacy Mode — per Cursor docs.)

Screenshots

Attach screenshots showing:

Agents chat with user messages and no assistant reply / “Planning next moves”

Design Mode enabled (blue Design) with annotation

Dual chat that does respond

53534f12-bc13-477d-bd76-d5187b68e27b
0aa55ee6-4251-4170-b568-818db123fdd0

Steps to Reproduce

  1. Open Cursor with a Dual / multi-root workspace.
  2. Open Agents Window (top-right).
  3. Start New Agent chat (or open an Agents Window chat) and send “hello” / “szia”.
  4. Observe: message appears; UI stuck on “Planning next moves” or idle; no assistant reply for minutes.
  5. Agents Window → File → New Browser → localhost port 3001 → enable Design Mode.
  6. Select an element / draw → Ctrl+L → type a change request in that Agents chat.
  7. Observe: request sits in Agents transcript with no agent action. Same text pasted into classic Dual/sidebar chat DOES get a reply.

Expected Behavior

Agents Window chats should stream replies like classic Agent chat. Design Mode Ctrl+L should land in a chat that actually runs the agent (or allow choosing destination). “Planning next moves” should not hang indefinitely without output.

Operating System

Windows 10/11

Version Information

IDE:
Version: 3.13.25
Commit: 31e8d61c448c7472e371505838a0fe34083dad50
OS: Windows 10/11 (build 26200)
x64

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey, thanks for the detailed report. The same chat splitting between Agents Window (Glass) and the classic sidebar, and only responding in the classic one, is a known issue. The two surfaces are different views of the same chat data, and the sync between them isn’t perfect yet. So it’s not your configuration.

Workarounds, from most reliable to backup:

  1. Keep a specific chat on only one surface. Don’t open it in both Agents Window and the classic window at the same time. For Design Mode + Ctrl+L, start the chat inside Agents Window via New Agent instead of reusing one that’s already open in the sidebar.
  2. Fully restart Cursor or run Developer: Reload Window. This usually rebuilds the chat-to-runtime binding.
  3. If the chat still gets stuck on “Planning next moves”, it might be network related. Go to Settings > Network > switch HTTP Compatibility Mode to HTTP/1.1 and restart. It doesn’t help everyone and sometimes only temporarily, but it’s worth trying. Also run Settings > Network > Run Diagnostics and send the result here.

A couple things to check so we can dig deeper:

  • The Request ID from the silent Agents Window chat. Use ... on the chat > Copy Request ID. In your post it’s still a template placeholder.
  • Was the silent chat created directly in Agents Window via New Agent, or is it the same chat that’s already open in the classic sidebar?

Let me know what worked, and send the Request ID and diagnostics output, then we can dig further.

Hey Dean, just letting you know that I am experiencing this problem too, running on Windows via WSL. Switching to HTTP 1.1 has (just now) unblocked me, so that’s at least a valid temporary fix (I hope it sticks!)

Just wanted to add a reply to flag that this is potentially more widespread than just OP here. Cheers.