Claude --resume sessions with 400 errors unusable

Claude Code --resume Flag 400 Error Bug Report

Executive Summary

The claude --resume command successfully loads sessions but any message sent to Claude within resumed sessions that previously encountered 400 errors results in consistent 400 API errors, making these sessions completely unusable.

Bug Description

Core Issue: Sessions resumed via claude --resume that contain previous 400 errors cannot process new user messages - every message triggers the same 400 API error pattern.

Command: claude --resume fixmcp --debug
Symptom: All user messages result in 400 "invalid_request_error" related to malformed JSON

Precise Reproduction Steps

1. Execute: claude --resume fixmcp --debug
2. Session menu loads successfully
3. Navigate to session #2 (63 messages) showing "API Error: 400" in summary
4. Press Enter to load session (session loads successfully)
5. Send ANY message to Claude (e.g., "hello claude, can you see this?")
6. BUG OCCURS: Receive 400 error response instead of normal Claude response

Captured Evidence

Automated Reproduction Successful

Using expect script automation, successfully reproduced the exact issue:

# Script successfully:
# 1. Loaded session #2
# 2. Sent message: "hello claude, can you see this?"
# 3. Captured 400 error response

Output: "400 ERROR FOUND - capturing remaining details..."

Session State Observation

• Session Menu: Displays correctly with sessions showing "API Error: 400" in summaries
• Session Loading: Sessions load without immediate errors
• Message Processing: ALL user messages trigger 400 errors
• Error Pattern: {"type":"error","error":{... consistently appears

Sample Error Format (from user example)

> are you ready to continue claude?
  ⎿  API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The request body is not valid JSON: no low surrogate in string: line 1 column 81749 (char 81748)"}}

Environment Details

• Claude Code Version: 1.0.24
• Node.js: v20.0.0
• OS: macOS 15.5.0 (Darwin 24.5.0, ARM64)
• Shell: zsh

Root Cause Analysis

Hypothesis: Sessions that encountered 400 errors have corrupted message history or malformed JSON in their stored state. When attempting to send new messages, the corrupted session data causes malformed API requests to be generated.

Key Indicators:

1. Session summaries correctly show "API Error: 400" - system is aware of the corruption
2. Sessions load successfully (metadata intact)
3. Every new message fails (message processing pipeline corrupted)
4. Error mentions "invalid JSON" and specific character positions

Impact Assessment

• Severity: High for affected sessions
• Scope: Sessions with previous 400 errors become permanently unusable
• Workaround: Start new sessions (loss of conversation history)
• Data Loss: Complete loss of session continuity and context

Technical Evidence Files

• captured_400_error_output.txt - Complete reproduction log
• complete_400_error.log - Detailed interaction log
• capture_400_error.exp - Automated reproduction script

Recommended Fix Strategy

1. Session Validation: Add pre-flight checks for session integrity before allowing resume
2. Corruption Detection: Implement detection for malformed JSON in session history
3. Recovery Options: Provide session repair/truncation capabilities
4. User Notification: Clear warnings when sessions cannot be safely resumed
5. Graceful Degradation: Allow partial session recovery (e.g., load up to last valid message)

Immediate Workaround

Use claude without --resume flag. Affected sessions are currently unrecoverable through the CLI.

---
Status: Confirmed and Reproduced
Priority: High (Breaks core functionality)
Category: Session Management / Data Corruption
Reporter: User via automated reproduction
Date: June 15, 2025