Queue-operation flood during rate limiting corrupts session and exhausts context

Resolved 💬 3 comments Opened Jan 22, 2026 by m-gris Closed Jan 25, 2026

Summary

When hitting rate limits, Claude Code enters a feedback loop that floods the session JSONL with thousands of spurious queue-operation entries. These entries:

  1. Are rendered as visible messages in the UI (showing /rate-limit-options spam)
  2. Count against the context window
  3. Eventually cause "Context limit reached" error

Reproduction

Exact trigger unknown, but observed after normal usage led to rate limiting.

Evidence

Session file: 7b1cd81c-4b47-4176-a34d-2103a7a8d9ac.jsonl

Records by type (before cleanup):
- assistant: 308
- user: 205
- system: 128
- queue-operation: 23,740  ← 12,599 were spurious "/rate-limit-options"

The spurious entries arrived in a burst within ~4 milliseconds:

{"timestamp": "2026-01-22T05:58:56.988Z", "count": 283}
{"timestamp": "2026-01-22T05:58:56.989Z", "count": 292}
{"timestamp": "2026-01-22T05:58:56.990Z", "count": 309}
{"timestamp": "2026-01-22T05:58:56.991Z", "count": 306}

All with structure:

{
  "type": "queue-operation",
  "operation": "popAll",
  "content": "/rate-limit-options",
  ...
}

UI symptoms

The conversation showed hundreds of lines of:

/rate-limit-options
/rate-limit-options
/rate-limit-options
...

Followed by "Context left until auto-compact: 0%"

Expected behavior

  • queue-operation entries should be internal bookkeeping, not rendered in UI
  • Rate limit handling should not create runaway loops
  • Internal operations should not consume context budget

Workaround

Manually filtered the JSONL:

jq -c 'select(.type != "queue-operation" or .content != "/rate-limit-options")' session.jsonl > cleaned.jsonl
mv cleaned.jsonl session.jsonl

Reduced from 24,680 → 12,081 lines.

Environment

  • Claude Code version: 2.1.12
  • Platform: macOS Darwin 23.3.0
  • Model: claude-opus-4-5-20251101

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗