Don't stop here
Hand-picked guides our readers explore right after this one.
Expert guide to Claude prompts with XML tags, artifacts, and complex reasoning
Read the guideStunning image generation with Midjourney prompt mastery
Read the guidePrompts for OpenAI Codex CLI coding agent for code generation, debugging, and multi-file projects
Read the guide'A previous response is still running in this conversation' means Claude's backend believes it is still generating something that already stopped arriving on your screen. It is a session-state conflict, not a sign that anything is broken on your machine, and the conversation stays locked until that orphaned generation clears. It typically follows a network drop, a timeout partway through a long response, or a heavy tool call that did not finish cleanly. Long conversations make it more likely, and if you use MCP connectors or agentic tool calls, timeouts or three or more sequential tool calls in a single turn can leave the backend stuck. In most cases waiting one to two minutes and doing a hard refresh releases it. If the thread stays locked, a new chat is the reliable escape.
'A previous response is still running in this conversation' blocks new messages
The reply stopped arriving but Claude still thinks it is generating
The conversation is locked while other chats work fine
It happened right after a network drop or a very long response
It follows a tool call or MCP connector that hung
The core cause: a response started, the connection to you broke, and the backend never registered that it finished. It keeps the conversation locked because as far as it knows a generation is still in flight.
A dropped connection or a timeout during a long answer leaves the generation half-finished server-side. Long responses hold the connection open longer, so they are more exposed.
A heavy tool call that hangs or times out can leave the turn unresolved. Users running MCP connectors report this most, especially when three or more sequential tool calls fire in one turn.
The longer the thread, the more state there is to manage per turn and the more likely a turn ends in an inconsistent state.
When to try: First, always
Give the backend a moment to time out the orphaned generation, then hard refresh the page (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac). This clears the majority of cases without losing the conversation.
When to try: When waiting and refreshing did not release it
If the conversation is still locked after waiting and refreshing, it is the reliable escape: open a new chat and send your request again. Copy any context you need across first, since the locked thread stays readable.
When to try: When the locked thread held important work
Before abandoning a long locked thread, scroll back and copy the key decisions and current state, or paste the important parts into the new chat as opening context. You keep continuity without waiting for the lock to clear.
When to try: If it recurs while using tools or connectors
If you use MCP connectors or agentic tools, reduce how many tool calls fire in a single turn. Three or more sequential calls in one turn make a stuck state much more likely. Break the task into separate turns and disable connectors you are not using.
When to try: To stop it recurring
Ask for output in parts rather than one very long response, and start new chats for new tasks. Shorter generations finish before a connection can drop, which is what creates the orphaned state.
When to try: When all conversations are affected
If every chat locks rather than one, check status.anthropic.com for an active incident. A service-wide problem produces this across the board and no local fix will help.
Ask for long output in numbered parts so each generation finishes quickly
Start a fresh chat per task instead of one very long running thread
Limit sequential tool calls per turn if you use MCP connectors
On an unstable connection, avoid kicking off very long generations
Contact Anthropic via support.claude.com only if conversations lock repeatedly across fresh chats and a stable connection, or if a thread stays locked for hours despite waiting and refreshing. Mention whether MCP connectors or tool calls were in use, since connector-related stuck states are a known trigger and that detail speeds up diagnosis.
Claude's backend thinks it is still generating a response that already stopped arriving on your end. It is a session-state conflict caused by an orphaned generation, usually after a network drop, a timeout during a long response, or a tool call that did not complete cleanly. The conversation stays locked until it clears.
Wait one to two minutes and do a hard refresh (Ctrl/Cmd+Shift+R). That resolves most cases. If the conversation is still locked, start a new chat and re-send your request, copying across any context you need.
No. The locked thread stays readable, you just cannot send new messages into it until the stuck generation clears. Copy anything important into a fresh chat if you need to keep working immediately.
Long conversations and heavy tool use are the main risk factors. If you run MCP connectors or agentic tools, three or more sequential tool calls in a single turn frequently leaves the backend stuck. Break work into separate turns, disable unused connectors, and request long output in parts.
Usually not. It normally affects one conversation while others work fine. If every chat locks, check status.anthropic.com, because a service-wide incident produces the same symptom and no local fix will help.