[BUG] VSCode extension stores user messages as per-character content blocks, causing premature 'Prompt is too long'

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The VSCode extension stores user messages as individual character content blocks instead of a single text block. This causes massive token overhead and premature "Prompt is too long" API errors, sometimes within 1 minute of starting a new session.

Root Cause Analysis

I analyzed the session JSONL file and found that user messages are stored like this:

Actual (broken):

{
  "message": {
    "content": ["以", "下", "の", "続", "き", "を", "進", "め", "て", ...]
  }
}

One message had 9,973 separate string entries for a ~10KB text input.

Expected:

{
  "message": {
    "content": [{"type": "text", "text": "以下の続きを進めて..."}]
  }
}

This pattern appears consistently across ALL user messages in the session:

• Message 1: 245 character entries
• Message 2: 130 character entries
• Message 3: 45 character entries
• Message 4: 9,973 character entries

When sent to the API, each entry becomes a separate content block with JSON overhead. A 10K character message effectively becomes ~300KB+ of API payload, consuming context window at 10-30x the expected rate.

Impact

• Sessions hit "Prompt is too long" within 1 minute of a fresh session (after /clear)
• The context usage indicator shows 50-64% remaining, but the API rejects the request
• /compact also fails because the conversation appears "too long" to the compaction model
• This creates an unrecoverable deadlock — cannot continue, cannot compact, can only /clear

Evidence from Session Log

Session: [redacted]
Claude Code: 2.1.42
Model: claude-sonnet-4-5-20250929
Platform: macOS (VSCode extension)

Line 1 (user): 245 entries, all single characters — "<", "l", "o", "c", "a", ...
Line 2 (user): 130 entries, all single characters
Line 3 (user):  45 entries, all single characters
Line 5 (user): 9,973 entries, all single characters — "以", "下", "の", ...
Line 10 (user): 1 entry (tool_result — normal)
Line 111 (user): 1 entry (tool_result — normal)

Note: Tool result messages (machine-generated) are stored correctly as single blocks. Only user-typed messages are split into characters.

Hypothesis

The VSCode extension appears to be capturing keystrokes or streaming input character-by-character and appending each character as a separate content entry, rather than joining them into a single text block before storing/sending.

Steps to Reproduce

1. Open Claude Code in VSCode (not terminal CLI)
2. Start a new session (/clear if needed)
3. Type a message (especially longer ones or paste text)
4. Continue for a few exchanges
5. Session hits "Prompt is too long" far earlier than expected
6. Inspect the session JSONL file — user messages will have per-character content arrays

Expected Behavior

User messages should be stored as a single text content block regardless of how input was received (typing, pasting, etc.).

Claude Model

Sonnet 4.5 (claude-sonnet-4-5-20250929)

Is this a regression?

Unknown — may have always existed in VSCode extension

Claude Code Version

2.1.42

Platform

Anthropic API (Max plan)

Operating System

macOS (Darwin 25.3.0, arm64)

Terminal/Shell

VSCode integrated terminal

Additional Information

Related issues that may share the same root cause:

• #15896 — [BUG] Prompt is too long (Claude for VS Code) — brand new session, 10 minutes
• #23751 — Compaction fails at 48% context usage (Opus 4.6)
• #25274 — Tool results embed full file content causing crashes
• #23047 — /compact fails when context limit reached