If you've been coding with Cursor's AI agent and suddenly watched the little “Thinking...” indicator spin forever with nothing happening, you're not alone. Cursor Composer 2.5 freezing is one of the most reported issues on the Cursor community forum right now, and it tends to hit right when you're in the middle of a long agent session with multiple files open. This guide walks through exactly why it happens, how to fix it right now, and what to do if it keeps coming back. No fluff, just steps that actually work, based on real reports from developers dealing with the same problem.
Quick-Fix Summary Box
If you're in a hurry, try these in order before reading the full guide: Wait 30–60 seconds some “stuck” states resolve on their own under heavy load.
Type “continue” or “go on” in the chat box and hit Enter — this unblocks many silent hangs. Reload the window Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows/Linux) → type “Developer: Reload Window” → Enter.
Start a new Composer chat instead of continuing the frozen one.
Switch the model from Composer 2.5 to another model (like Opus or GPT) temporarily, then switch back. Update Cursor to the latest version many freeze bugs get patched within weeks.
Restart Cursor completely (quit, not just close window) if reload doesn't help.
Check status.cursor.com Some freezes are short-lived backend incidents, not local bugs.
If none of these work, keep reading for the full step-by-step guide below. What Is Cursor Composer 2.5 Freezing?
Cursor Composer 2.5 freezing refers to the AI agent inside Cursor IDE getting stuck mid-task usually showing “Thinking…,” “Taking longer than expected…,” or just a spinning indicator with no response, no error, and no way to cancel cleanly. The agent appears to be running, but it never finishes the turn, never edits the file, and never replies.
This is different from a slow response. A slow response eventually completes. A freeze means the session is stuck in a state it can't recover from on its own. Cursor's own community has reported that some of these hangs simply never resolve without the user sending a short follow-up message like “continue” to unblock it.
It's also worth knowing this isn't unique to one version. Developers have reported similar stuck-on-thinking behavior across Composer 1, Composer 2, and now Composer 2.5, especially when running multiple agents and subagents at the same time, where the Composer agent gets stuck in “Thinking…” indefinitely with no error and no way to recover.
Why Does This Problem Happen?
Composer 2.5 is a complex agentic model; it doesn't just generate text, it plans, calls tools, edits files, runs terminal commands, and waits on responses from your local environment. Any weak link in that chain can cause a freeze. Here's the breakdown:
Long-running agent loops: Composer 2.5 is built for sustained, multi-step work. When a task runs long, the connection between the model's tool calls and Cursor's local execution can desync, leaving the UI showing “Thinking” with nothing actually happening behind it.
Subagent complexity: When Composer spawns subagents to handle parts of a task, a single subagent failure can stall the entire parent session without surfacing an error.
File sync issues: Some hangs are tied to local file sync features failing silently in the background.
Heavy local resource usage: Cursor IDE layers an AI runtime and your project files on top of a code editor. On lower-spec machines, or with many extensions and large repos open, resources get tight fast.
Network/API latency: Composer 2.5 runs through Cursor's backend, not a fully local model. A dropped or slow connection to the API can leave the UI in limbo.
Rate limiting or usage caps: If you've hit your plan's request limits, response times can balloon to the point where it looks frozen.
Corrupted chat/session state: Sometimes the conversation thread itself gets into a bad state after many turns, and the model can't recover within that thread.
Common Causes
Here's a quick-reference table of the most frequent root causes reported by users, mapped to typical symptoms:
Cause
Typical Symptom
Quick Test
Multi-agent / subagent overload
Stuck on “Thinking…” indefinitely, no error
Check if it happens only with multiple agents running
Long conversation thread
Freezes after many turns (“works fine for 5 turns then locks up”)
Start a fresh chat and see if it freezes as fast
Outdated Cursor build
Random hangs after an update, “hanging on generating”
Check Help > About for your version, compare to latest
Low system memory/CPU
Whole IDE feels sluggish before freeze
Check Task Manager / Activity Monitor during freeze
Network instability
“Taking longer than expected” message that never clears
Test on a different network or check connection
Account usage limits hit
Extremely slow responses, multi-hour delays
Check usage dashboard in Cursor settings
File sync errors
Hangs paired with a sync-related error tag in the console
Open Developer Tools console and look for sync errors
Specific model quirk
Only happens with one model, fine on another
Switch models and retest the same prompt
Step-by-Step Solutions
These are ordered from easiest/fastest to more involved. Try them in sequence.
- Send a Follow-Up Message This sounds too simple to work, but it's one of the most consistently reported fixes. If Composer 2.5 is stuck showing “Thinking…” or “Taking longer than expected…,” type a short message like: continue or go on, finish the task This nudges the session and frequently breaks the stall without losing your context.
- Use Cursor Developer Reload Window This is the single most effective built-in fix for Cursor Composer 2.5 not responding. Steps: Press Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows/Linux) to open the Command Palette. Type “Developer: Reload Window.” Press Enter. This reloads the Cursor window without closing your project, restarting the editor's internal state while keeping your open files. It clears most temporary glitches in the AI panel without you losing unsaved work (unsaved file changes are preserved, but an in-progress agent run will be cancelled).
- Kill the Stuck Chat and Start a New One If reload doesn't fix it: Close the frozen Composer tab/chat. Open a new Composer session (Cmd+I / Ctrl+I). Briefly re-paste the relevant context (you can copy the last few messages from the stuck chat before closing it, if accessible). This is the manual workaround developers are currently using to recover from the indefinite “Thinking” bug killing the chat, starting a new agent, and manually feeding it the previous conversation context even though it costs some time and tokens.
- Switch the Model Temporarily Open the model picker in the chat panel and switch from Composer 2.5 to a different model (Opus, GPT, or another available option), run a quick test prompt, then switch back to Composer 2.5. This often resets the underlying connection state for that chat session.
- Restart Cursor Completely A full restart (not just a reload) clears more than a window reload: Mac: Cmd+Q to fully quit, then reopen. Windows/Linux: Close all Cursor windows from the taskbar, confirm via Task Manager that no Cursor.exe process remains, then reopen.
- Check and Free Up System Resources How to fix Cursor IDE freeze issues tied to system load: Close unused browser tabs, Docker containers, or other memory-heavy apps. Check CPU/RAM usage in Activity Monitor (Mac) or Task Manager (Windows) while Cursor is open. Close large or unrelated workspaces — having multiple huge repos open in separate windows adds up fast.
- Update Cursor to the Latest Version Go to Cursor menu > Check for Updates (or download the latest installer from cursor.com). Freeze bugs tied to specific builds are commonly patched within days to weeks of being reported, so an outdated build is a common and easily fixed cause.
- Check Your Network Connection Since Composer 2.5 runs through Cursor's backend rather than fully on your device, a flaky connection can cause a hang that looks identical to a true freeze: Try a wired connection or different Wi-Fi network. Disable VPN temporarily to rule out interference. Check Cursor's status page for any ongoing outages.
- Verify You Haven't Hit Usage Limits Open Settings > Usage inside Cursor to check your remaining quota. If you're on a capped plan and have exhausted your fast-request allowance, responses can slow dramatically to the point of feeling frozen rather than failing outright.
- Check Cursor's Status Page and Share Your Request ID Sometimes the freeze isn't local at all; it's a short-lived backend incident on Cursor's side. Before assuming the problem is on your machine: Visit status.cursor.com to check for any active or recently resolved incidents affecting Composer. If you need to report the issue, find your Request ID from the affected conversation (Cursor's official troubleshooting docs explain where to find this) and include it in your forum post or support ticket. In confirmed cases on the Cursor community forum, this exact step is what Cursor's own support team asks for first; it lets them trace the specific backend run that got stuck, rather than guessing. Advanced Troubleshooting Methods If the basic steps don't resolve it, or the freeze keeps recurring, try these: Inspect the Developer Console Open Command Palette → “Developer: Toggle Developer Tools.” Check the Console tab for errors at the moment of the freeze — look especially for sync-related errors, which some users have linked to hangs alongside a file-sync error appearing in the logs when Composer hangs on generating. Disable Conflicting Extensions Some third-party extensions interfere with Cursor's AI panel rendering or background processes. Disable non-essential extensions one at a time and retest. Clear Cursor's Local Cache/Settings (Last Resort) If a corrupted local state is suspected: Back up any custom settings/snippets first. Close Cursor completely. Locate the Cursor application support/config folder for your OS and rename (don't delete) the cache directory. Reopen Cursor — it will rebuild a fresh cache. Avoid Over with Subagents If you're running multi-agent or subagent workflows, scale back to a single agent for the task that's freezing. This directly addresses the subagent-related stuck-thinking bug currently being tracked by Cursor's team, where users have proposed a “Repair” button or /repair command that would auto-spawn recovery logic for stuck multi-agent sessions — a fix not yet shipped as of this writing. Reproduce in a Minimal Project Open a small test project and run a simple Composer 2.5 prompt. If it freezes there too, the issue is environmental (Cursor build, network, system) rather than tied to your specific large codebase. Real-World Examples Example 1: The “5-turn freeze” A developer reported that Cursor would freeze completely after about five turns of conversation in a new window when using Composer, while Claude Code kept finishing long tasks without issue. The fix that worked: starting a fresh chat every few turns instead of letting one thread run long, plus a full app restart between sessions. Example 2: The silent “Thought Briefly” stop Another user described the agent working normally, then abruptly displaying “Thought briefly” before stopping with no error and no indication of whether it was still working or had finished. Sending “continue” resolved it most of the time; a window reload fixed the rest. Example 3: Crash after composer use One report described Composer working for a couple of seconds before freezing and then crashing with a “window terminated unexpectedly” error, even after a full reinstall. In this case, the issue was isolated to the Composer panel specifically (regular chat worked fine), pointing to a panel-specific rendering bug rather than a system-wide problem — a Developer Reload Window combined with disabling extensions resolved it for most affected users. Example 4: Usage-limit slowdown mistaken for a freeze A Pro plan user reported things grinding to a near-stop, taking what felt like a full day per request, after hitting their 500-request premium limit — not a true freeze, but indistinguishable from one without checking the usage dashboard first. Example 5: Cursor's own team confirms a server-side incident In one well-documented forum thread, a user reported the exact “Thinking… indefinitely with no error” problem in a multi-agent setup. A Cursor team member responded directly, asked for a Request ID, and confirmed there had been a short-lived issue with Composer 2.5 on Cursor's status page that was already resolved. The user confirmed the original freeze was fixed — but a new, related issue then appeared: in multitask mode with several sub-agents running, the final summary sometimes failed to generate or display, with the “Open” button not responding. Restarting Cursor was the workaround that consistently fixed it. This shows two important things: first, that some freezes really are temporary backend incidents you can verify on Cursor's status page; second, that fixing one freeze bug can surface a closely related one in multi-agent workflows, so it's worth retesting after any fix. Latest Updates (2026) Here's what's changed recently that's directly relevant to this issue: Composer 2.5 launched May 18, 2026 as Cursor's newest in-house coding model, built on the same Kimi K2.5 checkpoint as Composer 2, with improvements aimed at sustained long-running tasks and more reliable instruction-following — exactly the kind of long-session work where freezes have historically been reported most. Targeted RL feedback during training: Cursor specifically trained Composer 2.5 to correct mistakes at the exact point they occur during long coding trajectories, rather than only at the end of a run, which Cursor states should reduce the kind of drift that leads to stuck states. Composer 2 → 2.5 auto-routing: As of the June 2026 SDK update, scripts and integrations still pinning the older “composer-2” model slug are now automatically routed to Composer 2.5, so some freezing reports may actually involve 2.5 running under an old reference. Subagent nesting expanded: The June 18, 2026 release introduced support for subagents spawning their own subagents, each with its own prompt and model — a feature that increases the risk of the multi-agent stuck-thinking bug if not used carefully, since more nesting means more points of failure in a session. Request correlation IDs added: Recent SDK updates added a platform-generated requestId on every run, persisted across stores, which makes it easier for Cursor support to trace exactly where a session stalled if you report a freeze with that ID. Workspace-scoped run lookups fixed: A recent fix addressed spurious “agent not found” errors that could resemble a freeze when the bridge ran as a subprocess in a different workspace context. A new multitask-mode bug surfaced after the original fix: Once the core “Thinking” freeze was resolved, users running multitask mode with several sub-agents reported the final summary sometimes failing to generate or open, with the “Open” button stuck unresponsive. A full Cursor restart is the current workaround while Cursor's team investigates further — worth knowing if your freeze seems to come back in a slightly different form after updating. “Fast” variant remains the default and costs more: Community discussion around the May 2026 launch confirmed Composer 2.5 Fast — the default interactive mode — is priced roughly 3x higher than the Standard tier and is also forced onto sub-agent calls, which can contribute to faster-than-expected usage cap exhaustion and the slowdowns that follow. Active bug tracking: The multi-agent stuck-on-thinking issue remains an open, acknowledged bug on Cursor's community forum as of recent reports, with a community-proposed “Repair” command still pending official implementation. Best practice going forward: Since Composer 2.5 is now the routing default for nearly all sessions, keep Cursor updated to the latest build, avoid deep subagent nesting on tasks that don't need it, and start new chats periodically during long sessions rather than letting one thread run for hours. Troubleshooting Checklist Use this as a quick pass before escalating to support: ☐ Waited at least 60 seconds before assuming it's frozen ☐ Sent a “continue” follow-up message ☐ Ran Developer: Reload Window ☐ Started a fresh Composer chat ☐ Tried switching models and back ☐ Fully quit and reopened Cursor ☐ Checked Activity Monitor / Task Manager for resource limits ☐ Confirmed Cursor is on the latest version ☐ Tested on a different network connection ☐ Checked usage/quota limits in Settings ☐ Checked Developer Console for sync or other errors ☐ Disabled non-essential extensions ☐ Reproduced (or not) the issue in a small test project ☐ Reduced subagent nesting if using multi-agent workflows ☐ Checked status.cursor.com for active incidents ☐ Noted the requestId (if visible) for any support ticket When to Contact Support Reach out to Cursor support (via the in-app help icon or forum.cursor.com) if: The freeze happens on every single session regardless of project size or model. You've completed the full checklist above and it still recurs. You're seeing a crash with a specific error code (e.g., “window terminated unexpectedly... code: 5”). The issue started right after a specific Cursor update and a rollback isn't possible. You have a requestId or session ID from the Developer Console you can share — this dramatically speeds up diagnosis. You're on a paid plan and the slowdown is tied to usage limits you believe are incorrect. When filing a report, include: your OS and Cursor version, the model in use (confirm it's Composer 2.5, not an older alias), whether subagents were active, and steps to reproduce if known. The community forum (forum.cursor.com) is also a fast way to check if others are seeing the same bug in real time. FAQ Section
- Why does Cursor Composer 2.5 keep freezing on “Thinking”? It's usually tied to long agent sessions, subagent overload, or a desync between the model's tool calls and your local environment. It's a known, actively tracked issue rather than something wrong specifically with your setup in most cases.
- Is Cursor Composer 2.5 stuck on thinking of a bug or my system's fault? Both are possible. It's a confirmed bug on Cursor's side in multi-agent scenarios, but local factors like low memory, outdated builds, or network issues can trigger or worsen it.
- How do I force Cursor to unfreeze without losing my work? Try sending “continue” in the chat first — it's non-destructive. If that fails, use Developer: Reload Window, which preserves open files but cancels the stuck agent run.
- What is Cursor Developer Reload Window and how do I use it? It's a built-in command that refreshes Cursor's internal state without closing your project. Open it via Command Palette (Cmd+Shift+P / Ctrl+Shift+P) and search “Developer: Reload Window.”
- Does switching models fix Cursor Composer 2.5 not responding? Often, yes. Switching to another model and back can reset the connection for that chat session, even if you plan to keep using Composer 2.5 afterward.
- Is this freezing issue specific to Composer 2.5, or did older versions have it too? Older versions including Composer 1 and Composer 2 had similar stuck-on-thinking reports, so it's a recurring pattern tied to the agentic architecture rather than something new in 2.5 alone.
- Can a slow internet connection cause Cursor AI browser freeze symptoms? Yes. Since Composer 2.5 calls Cursor's backend over the network, an unstable connection can produce a hang that looks identical to a true software freeze.
- Will updating Cursor fix the freezing problem? It often helps, since known freeze bugs are typically patched within weeks of being reported. Always check for updates before deeper troubleshooting.
- Why does Cursor freeze specifically with multiple agents or subagents running? Each subagent is a separate point of failure. If one stalls without throwing a visible error, it can lock up the entire parent session, which is the core mechanism behind the most-reported version of this bug.
- Should I downgrade from Composer 2.5 if it keeps freezing? Not as a first step. Since Cursor now automatically routes older model references to 2.5, downgrading isn't always possible or effective. Try the full troubleshooting checklist first, and report persistent issues to Cursor support with reproduction steps.
- How do I know if the freeze is a Cursor server issue and not my computer? Check status.cursor.com. Cursor's support team has confirmed in forum threads that some “stuck on Thinking” reports were tied to short, already-resolved backend incidents with Composer 2.5 — in those cases, the fix is simply to wait or retry, not to troubleshoot your own setup.
- The freeze is gone, but now Composer won't show its final summary in multitask mode — is that the same bug? It's a related but separate issue reported after the main stuck-on-thinking bug was patched. When using multitask mode with several sub-agents, the final summary can fail to generate or open. A full restart of Cursor is currently the most reliable workaround while this is investigated. Conclusion Cursor Composer 2.5 freezing and getting stuck on thinking is frustrating, but it's a well-documented, actively tracked issue with practical fixes you can apply right now. Start small — a follow-up message or a Developer Reload Window solves most cases in under a minute. If the problem persists, work through system resources, network checks, and subagent usage before assuming something deeper is wrong. Cursor's team continues to ship updates aimed at long-running task stability, and Composer 2.5 itself was specifically trained to handle sustained agent work better than its predecessor. Keep your build updated, avoid unnecessary subagent nesting, and don't be afraid to start a fresh chat rather than fighting a stalled one. If you've tried everything here and it still won't budge, the forum and support channel are your fastest path to a real fix — and your report helps get the underlying bug closer to resolved for everyone else hitting it too.