[BUG] /resume and --resume fail to find sessions whose first user message exceeds ~15KB

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?

Sessions become permanently invisible to /resume, --resume, and the session picker when their first non-system user message exceeds approximately 15KB. Running /resume <session-id> or claude --resume <session-id> returns:

Session <session-id> was not found.

The .jsonl session file exists on disk and is valid — the session simply cannot be found by any resume mechanism.

Root cause (traced through the minified CLI source):

The session metadata extractor reads only the first 16,384 bytes of each .jsonl file. The first-prompt parser then processes this buffer line-by-line to extract firstPrompt. A typical continued session starts with:

1. file-history-snapshot line (~235 bytes) — skipped (not user type)
2. Continuation message [Request interrupted by user for tool use] (~487 bytes) — skipped by filter regex
3. The actual first user message — only ~15,662 bytes of buffer remain

If this message exceeds the remaining buffer, the JSON line is truncated. JSON.parse() fails in a catch block that silently continues. The parser returns "". Then the session filter function checks:

if (!firstPrompt && !customTitle) return null;

The session is silently dropped from results. The paginated loader never includes it, so the UUID lookup in the resume handler fails.

This affected 26 out of 42 sessions in my project — every session started by pasting an implementation plan.

What Should Happen?

/resume <session-id> and claude --resume <session-id> should find and resume any session whose .jsonl file exists, regardless of the size of the first user message.

Error Messages/Logs

Session <session-id-here> was not found.

(Same error for every affected session. The error is a normal UI message, not a crash.)

Steps to Reproduce

1. Start a new Claude Code session
2. As the very first message, paste a prompt longer than ~15KB (e.g., a detailed implementation plan). Example:

```
Implement the following plan:

# My Feature Plan

## Context
[... paste enough text to exceed 15,000 characters total ...]
```

1. Work in the session normally, then exit
2. Run claude --resume <session-id> using the session ID from the .jsonl filename
3. Result: Session <session-id> was not found.

Why it happens: The session's .jsonl file starts with:

• Line 1: {"type":"file-history-snapshot",...} (~235 bytes)
• Line 2: {"parentUuid":"...","type":"user","message":{"content":[{"text":"[Request interrupted by user for tool use]"}]}} (~487 bytes)
• Line 3: {"parentUuid":null,"type":"user","message":{"content":"Implement the following plan:..."}} (~15,500+ bytes)

The 16KB read buffer (hardcoded to 16,384 bytes) is exhausted partway through Line 3. The truncated JSON fails to parse, firstPrompt stays empty, no customTitle exists, and the session filter returns null.

Workaround: Inject a custom-title entry into the .jsonl file:
{"type":"custom-title","customTitle":"My Title","sessionId":"<uuid>"}
This is read from the file tail (last 16KB) and bypasses the head-read bug.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.42 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Suggested fix options (in order of simplicity):

1. Increase the metadata read buffer from 16,384 to 131,072 (128KB) — covers most realistic first messages
2. Multi-chunk read in the first-prompt parser — if the buffer ends mid-line without finding a firstPrompt, read additional chunks
3. Skip the firstPrompt requirement for UUID-based lookups — when the user provides an exact session UUID via --resume, bypass the session filter entirely and load the session directly. The firstPrompt/customTitle filter makes sense for the interactive session picker but not for explicit UUID lookups.

Option 3 is the most robust since it separates "display filtering" from "session existence."