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:
- Are rendered as visible messages in the UI (showing
/rate-limit-optionsspam) - Count against the context window
- 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-operationentries 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
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗