Conversations with large first messages (images) are invisible in Past Conversations due to 64KB head buffer limit

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/26140
2. https://github.com/anthropics/claude-code/issues/25984
3. https://github.com/anthropics/claude-code/issues/25721

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

⚠️ This is NOT a duplicate — the v2.1.47 fix (16KB→64KB) did not resolve this

I'm hitting the exact same bug on the latest version of the VS Code extension (v2.1.63). The buffer constant is still fK = 65536 in extension.js. I can confirm the root cause analysis in this issue is 100% correct.

Important distinction: Issues #26140, #25920, #25721 were about the CLI /resume path with a 16KB buffer (eS$). That was fixed in v2.1.47 by @ashwin-ant (commit b757fc9). However, the VS Code extension has a separate code path (fetchSessions() → FW() → fK = 65536) that was never fixed — the buffer was already 64KB in the extension, and it's still 64KB in v2.1.63.

My reproduction: no images needed — IDE context alone exceeds 64KB

The original report demonstrates this with base64-encoded screenshots. I want to add that images are not required — the VS Code extension itself injects large IDE context (<ide_opened_file>, <system-reminder>, CLAUDE.md contents, auto-memory) into the first user message, routinely inflating it well beyond 64KB.

Environment:

• Claude Code VS Code Extension v2.1.63 (latest, darwin-arm64)
• macOS Darwin 25.2.0
• Model: claude-opus-4-6

7 affected sessions from my project:

| Session ID | First type:"user" line size | Visible? | Content |
|---|---|---|---|
| 4855730f-... | 372 KB | ❌ Hidden | IDE context + user text |
| 20fa070c-... | 1,008 KB | ❌ Hidden | IDE context + user text |
| 69fa37ed-... | 114 KB | ❌ Hidden | IDE context + user text |
| 4 other sessions | 65–400 KB | ❌ Hidden | IDE context + user text |

None contain images. The inflation comes entirely from the extension's own context injection.

Code path in v2.1.63 (confirming it's unchanged)

// extension.js (v2.1.63)
var fK = 65536;  // ← hardcoded 64KB buffer

async function FW(z) {
    let U = await sK.open(z, "r");
    let v = Buffer.allocUnsafe(fK);
    let N = await U.read(v, 0, fK, 0);  // ← reads only 64KB head
    // ... reads 64KB tail ...
    return { head, tail, mtime, size };
}

// In fetchSessions():
let q = uK(x, "customTitle") || uK(x, "summary") || LW(j);
if (!q) return null;  // ← session silently dropped when all three fail

LW(head) (the prompt extractor) tries JSON.parse() on truncated lines → fails silently → returns null → session is invisible.

Why increasing the buffer won't fix this long-term

The extension injects unbounded context into the first message — IDE selections, opened files, system reminders, CLAUDE.md, memory files. This will only grow as features are added. Bumping fK to 1MB is a band-aid.

Suggested fix: write a metadata header early in the .jsonl

When creating a new session, write a small metadata line as the 2nd or 3rd line (after queue-operation):

{"type":"session-meta","summary":"First 200 chars of user prompt...","created":"2026-03-02T12:00:00Z"}

This guarantees LW() always finds parseable content within the 64KB head, regardless of how large subsequent messages are. Minimal code change, maximum robustness.

Workaround (fragile)

Manually appending a summary entry to the .jsonl tail:

{"type":"summary","summary":"Description","leafUuid":"<last-uuid>"}

This works via uK(tail, "summary"), BUT it's fragile — the extension continues appending data (subagent results, file-history-snapshots) which can push the summary outside the 64KB tail window, making the session invisible again. I've observed this happen in practice.

---

@ashwin-ant This is a continuation of the buffer issue you fixed in v2.1.47. The 16KB→64KB increase resolved the CLI /resume path, but the VS Code extension's FW() / fetchSessions() has the same class of bug — and it's triggered much more easily because the extension itself injects large IDE context into the first message. Still present in v2.1.63.

@hackyon-anthropic This lives in the VS Code extension's extension.js — fK = 65536 in FW() and the LW() title extraction chain. An architectural fix (metadata header) would be more robust than bumping the buffer.

cc @chrislloyd @vbhavsar (related: #26140, #25721, #25920)

I independently found the same issue on Windows 11 + VSCode extension v2.1.69.

In my case, the first user message contained a base64-encoded PDF (~2.3MB), making line 4 of the .jsonl file 2,361,422 bytes. The 64KB head buffer in Ys() truncates this line, JSON.parse() fails, and Ts() returns empty ? so UU() returns null and the session is excluded.

As a temporary workaround, I changed sV=65536 to sV=4194304 in extension.js and the session appeared immediately.

This issue is part of a family of ~20 bugs that all stem from the same root cause: the VS Code extension reads titles by raw-string-scanning the last 64KB of each JSONL file, which causes title eviction on long sessions, cross-session contamination from tool result content, and overwrite-on-resume.

See #33165 (comment: https://github.com/anthropics/claude-code/issues/33165#issuecomment-4070011372) for the full root cause analysis, all related issues collected, and a working workaround (persistent title registry + hook).

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This bug is still present in v2.1.108 and silently affects many users reporting "session loss".

I independently investigated disappearing sessions on Windows 11 / VS Code and traced it to the same 64KB D2 buffer in Pp() → Yq4(). In my case, 22 out of 193 sessions were silently dropped — every single one had a first user message containing pasted screenshots with base64 data exceeding 64KB.

Additional findings:

• The sessions are present in sessions-index.json (the CLI knows about them) but the VS Code extension's listSessions() → Fd() → xZ4() → Cp() → Pp() chain drops them because Pp() returns null
• Multiple open "session loss" issues (#38691, #9258, #41455, #31787) likely have this as root cause but attribute it to race conditions or update data loss
• This is not edge-case behavior — attaching screenshots is a core workflow for VS Code users

Workaround that works: Inject a {"type":"ai-title","aiTitle":"..."} record after the queue-operation lines at the top of each affected .jsonl file. This puts the title within the 64KB head window. All 22 sessions reappeared immediately after VS Code reload.

Suggested fix: Write the ai-title record early in the .jsonl file (immediately after generating it), not just inline after the first assistant response. This would be a one-line change and permanently prevent the issue. Alternatively, increase D2 to 1MB, or fall back to a generic title instead of returning null.

Closing this as "not planned" means every user who pastes screenshots in their first message permanently loses those sessions from the sidebar. Please reconsider.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.