Bug: User input is ignored and "Previous query still processing" error is shown

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/1982
2. https://github.com/anthropics/claude-code/issues/3133

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Same Issue, No way to queue up commands anymore

+1

plus 1 !!!!!!!!!!!!!!!cant talk to claude anymore while hes working to redirect him or make sure he remember stuff

never did that before today

+1 This is not a good "feature".

plus 1

+1

+1

My experience was similar, but even worse: my input was ignore, but Claude Code also hung.

I entered a prompt that required a lot of thinking and tool use. I got a 'call to action' from Claude Code suggesting that I could 'queue up commands for Claude by pressing enter' (paraphrasing). I tried this, and then Claude Code ended up hanging with the message "Previous query still processing. Please try again.". I was able to escape to return to input mode, but none of my inputs had any effect. I had to close CC and start over.

Yup! This is happening with CC right now and it's effectively frozen running a problematic bash operation and there's no way to have it stop, not even cancellation using Esc!

This tends to occur when you hit "Compacting conversation…". You can exit the conversation, then /resume to the same chat and try again (this works at times).

Though I usually take this as a sign the the conversation got too long and start a new one.

This might be fixed as of v1.0.84:
https://github.com/anthropics/claude-code/commit/da6d2f715e5081bf304e23aff6f282a73f0f9dc7

Fix Claude sometimes ignoring real-time steering when wrapping up a task

Make sure to update Claude by running 'claude update' and report if you guys see this again.

Still see this in v1.0.84.

<img width="447" height="48" alt="Image" src="https://github.com/user-attachments/assets/36456e99-68a3-4182-b0fa-03d3d9853a84" />

Can't interrupt and have to restart.

Stupid feature

+1, have to quit and enter again.

+1

+1 also never see claude make todo lists automatically anymore and never talks to himself

Error still seen on 1.0.88

Experiences like this without recompense from Anthropic are among the reasons I've decided to cancel my max subscription. All users should be credited when things like this happen. Instead, we're meant to just expect it as part of the ongoing development experience. If claude code is in beta, we shouldn't pay so much for it.

⏺ Previous query still processing. Please try again.
⎿ API Error (Request timed out.)

I’m not sure if this is connected to running Claude Code in another terminal session at the same time, but it makes working across multiple terminals really difficult. I can’t help but wonder if that’s intentional.

---

Note: running /exit and restarting with --continue sometimes resolves the issue—so it might just be related to periods of high demand.

Hi! I ran into an issue with Claude Code after a brief power outage interrupted the CLI session.

claude --version
1.0.109 (Claude Code)

What I observed:
After the interruption, claude stopped talking to himself and restarting claude did not recover the previous prompt context using the /resume command. Had to start a new session and earlier conversation/state was lost.

What I expected
Either automatic recovery or an HTTP error while trying to process while the network was down. I would appreciate if we could resume our work once the network is back online.

Notes
The outage was short (under half a minute) and caused an abrupt terminal drop.

A session autosave/restore mechanism would make sudden disconnects less costly.

Thanks!

I hadn't seen it until this evening. Now it's happening almost every time, instead of queueing the new response as it has always done in the past. (Still using Sonnet 4.5 and same settings as always.)

just started happening to me this evening too.

It gets crazy in 2.0.8.

agree 2.0.8

It is also triggered by post tool hooks, without any user interaction. After it gets into this state all form of inputs are rejected and the only way out is closing claude and opening again.

i get this quite often since 2 days

Same, its like it vanishes and causes a lot of issues.

This is indeed, an issue. Very annoying.

This bug drives me crazy

+1 This feature is annoying

Just sharing image 😃 <img width="885" height="274" alt="Image" src="https://github.com/user-attachments/assets/3d154a93-4ee5-49cf-bd4d-b83be9795910" />

Input Ignored During State Transition - Race Condition

32 comments. Classic race condition between UI accepting input and backend being ready.

Root Cause

When Claude finishes a response, there's a ~200ms window where:

• Backend transitions from "processing" → "idle"
• UI already shows prompt as ready
• User types + hits ENTER
• Backend rejects with "Previous query still processing"

This is a state synchronization bug.

Technical Explanation

// Current (broken) state machine:
state: 'idle' | 'processing'

// When response completes:
1. Backend finishes API call (state still 'processing')
2. UI renders response
3. UI enables input field  // ← TOO EARLY
4. User types + submits
5. Backend checks state → still 'processing' → rejects
6. Backend transitions to 'idle' (100ms later)

The UI enables input BEFORE backend confirms state transition.

Immediate Workaround

Option A: Wait 1 Second (manual delay)

Just wait 1 second after Claude's response appears before typing.

Option B: Look for Ready Indicator

Wait until status line shows no spinner/activity indicator

Option C: Use Batch Mode (no race condition)

# Instead of interactive:
claude -p "prompt 1" && claude -p "prompt 2"

Proper Fix (For Anthropic Team)

Option 1: Queue Input

class InputQueue {
  private pending: string | null = null;
  
  submit(input: string) {
    if (state === 'processing') {
      this.pending = input;  // Queue for when ready
    } else {
      processInput(input);
    }
  }
  
  onStateChange(newState: 'idle') {
    if (this.pending) {
      processInput(this.pending);
      this.pending = null;
    }
  }
}

Option 2: Disable Input Until Confirmed Ready

// UI should:
async function onResponseComplete() {
  // 1. Render response
  await renderResponse();
  
  // 2. Wait for backend confirmation
  await waitForStateConfirmation('idle');
  
  // 3. THEN enable input
  inputField.enable();
}

Option 3: Add Visual Feedback

// While transitioning:
> Previous query still processing. Please wait... [===> ]

// When ready:
> Ready for input █

Why This is Intermittent

The race condition only triggers if you type fast enough to hit the 100-200ms window. Most users naturally wait longer, so they never see it.

Power users (who type immediately) hit this constantly.

Test Case

To reproduce reliably:

# 1. Send a short query:
claude
> What is 2+2?

# 2. AS SOON AS you see "4", immediately type:
> Next question

# 3. Hit ENTER within 100ms of seeing response
# → Should trigger "Previous query still processing"

Why Input Disappears

The input isn't "ignored" - it's rejected and cleared because backend thinks it's spam/double-submission.

Fix: Instead of clearing, show error but KEEP the typed text:

⚠️ Previous query still processing. Press ENTER again to retry.
> [your typed text still here]

---

Workaround summary: Wait 1 second after response before typing. Annoying but works 100%.

Real fix: Backend must SIGNAL when ready, UI must WAIT for signal before enabling input.

Seeing this on v2.0.60 on Ubuntu in KiTTY SSH. Inconsistent but it definitely has been happening more lately.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

+1 Still experiencing this in v2.1.x

Specific scenario: When I type input at the exact moment Claude's output finishes rendering, the input disappears entirely and is not processed. This is a race condition between the output completion and input buffer handling.

The timing window is small but reproducible - it happens when you're typing ahead while waiting for output to finish.

This "Previous query still processing" error is a race condition between the UI accepting input and the backend being ready.
Workaround 1 — Wait for the prompt indicator:
The > prompt character appears when Claude is ready for input. If you type before it appears (during the brief transition), the input gets swallowed. Wait for the prompt indicator before typing.
Workaround 2 — Use up-arrow to recall lost input:
If your message disappears, press the up arrow key — Claude Code may have saved it in the input history even if it wasn't processed.
Workaround 3 — Compose in clipboard and paste:
For important/long prompts, type them in your editor and paste with Ctrl+V. This way you never lose the text even if it's rejected.
Workaround 4 — Slow down tool call execution:
The race condition is more likely when Claude finishes a rapid series of tool calls. Adding a small delay via hook can help:

{
  "hooks": {
    "Stop": [
      {
        "hook": "bash -c 'sleep 0.5'"
      }
    ]
  }
}

This adds a half-second pause after Claude stops, giving the UI time to fully transition to the ready state.

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.