AppHang on Windows when loading a 121 MB conversation — every inlined image is stored twice in the JSONL transcript

AppHang when loading a large conversation (121 MB transcript, 106 embedded images stored twice)

Summary

The Claude desktop app becomes unresponsive and is killed by Windows ("Quiesce" hang)
when opening a conversation whose transcript file has grown to ~121 MB and contains
~106 embedded JPEG images, each written twice into the transcript. The app hung 3 times in a row on this conversation; one of
those hangs was recorded by Windows Error Reporting as an AppHang event.

Environment

| | |
|---|---|
| App version | Claude 1.26832.0.0 (x64, MSIX package Claude_1.26832.0.0_x64__pzs8sxrjxfjjc) |
| Executable | C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\claude.exe |
| OS | Windows 10 Pro for Workstations, 10.0.19045 (build 19045), 64-bit |
| RAM | 32 GB |

Reproduction

1. Have a long-running conversation in which 106 image files (scanned civil-record

photos) are read from disk with the Read tool over 9 days. Each file is read
exactly once; no image is ever re-read.

1. Open (or reopen) that conversation in the desktop app.
2. The UI freezes; Windows marks the process as not responding and terminates it.

Transcript in my case (path generalized):
%USERPROFILE%\.claude\projects\<project-slug>\<conversation-uuid>.jsonl

Measured content (produced by streaming the file line by line, then re-measured
independently a second time with the same result):

• 126,843,166 bytes / 2,203 lines, measured 2026-08-09 22:39. The file was still

growing while I measured, hence the small difference from the 126,835,876 bytes
originally reported.

• 106 image reads — 106 distinct file paths — 106 distinct SHA-256 digests.

Histogram of reads per file: {1: 106}.

• 212 "type":"image" content blocks for those 106 images (see below).
• 116 "media_type" declarations = 106 under message.content[].content[].source

plus 10 under toolUseResult.attachments[].

• 88 lines exceed 1 MB. Largest line: 1,365,658 bytes. Median line: 1,385 bytes.

Root cause: every image is written twice
----------------------------------------

Each image is stored twice in the transcript, under two different keys:

• message.content[].content[].source.data — the copy sent to the model
• toolUseResult.file.base64 — a second copy kept by Claude Code

Verified by SHA-256: all 106 digests found under the first key are also present under
the second.

| Item | Bytes | Share |
|---|---:|---:|
| Images, model copy | 61,282,448 | 48.3% |
| Images, second local copy | 61,282,448 | 48.3% |
| Everything else (9 days of conversation text, attachments, signatures) | 4,278,270 | 3.4% |

96.6% of the file is image data, and half of that is a duplicate. Reported token usage
shows no matching increase, which suggests the second copy is never sent over the wire —
but that cannot be proven from the transcript alone.

Subagent transcripts do not have this duplication: across the 39 subagent files of this
session, toolUseResult holds 0 bytes of image data. Delegating the same 106 reads to
subagents would have left a 4.0 MB main transcript instead of 126.8 MB.

Why nothing was ever pruned: this session ran on a 1M-token context window and peaked at
553,221 input tokens, so auto-compaction never triggered and all 106 images stayed in
context for 9 days.

Expected

Opening a large conversation should stream/virtualize history rather than block the UI
thread, or at minimum show progress and stay responsive.

Actual

The process stops pumping messages and Windows kills it.

Windows Event Viewer evidence

Application Hang, Event ID 1002 — 2026-08-09 17:05:17:

Le programme claude.exe version 1.26832.0.0 a cessé d'interagir avec Windows et a été fermé.
 ID de processus : 34b0
 Heure de début : 01dd280d585bcc8b
 Chemin d'accès à l'application: C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\claude.exe
 ID de rapport : e2661a22-3e68-4bc0-a71b-097627ec36d6
 Nom complet du package défectueux : Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
 Type de blocage : Quiesce

Windows Error Reporting, Event ID 1001 — same timestamp:

Nom d'événement : MoAppHang
P1 : Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
P2 : praid:Claude
P3 : 1.26832.0.0
P4 : 6a550db4
P5 : 4185
P6 : 2097152
ID de rapport : e2661a22-3e68-4bc0-a71b-097627ec36d6

WER archive folder:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppHang_Claude_1.26832.0_d36dc29c1b4217ecf40a3e61c40e71b8e1ca47_efa4cdb5_006ff076-3ca8-4d14-ad90-ad3595da1e55

Note: the app hung 3 times, but only this one produced an AppHang / WER record — the
other two left no entry in the Application log (they appear to have exited without
Windows classifying them as a hang).

Possibly related

An earlier RADAR_PRE_LEAK_64 leak-detection report was filed against an older build,
which may point at the same memory-growth path:

2026-07-10 22:49:24 — Windows Error Reporting, Event ID 1001
Nom d'événement : RADAR_PRE_LEAK_64
P1 : claude.exe
P2 : 1.20186.0.0
P3 : 10.0.19045.2.0.0

Suggested direction

Base64 images kept inline in the JSONL transcript mean the whole history — images
included — is decoded on load. Storing image payloads out-of-line (content-addressed
files referenced by the transcript) and lazily loading them would cap the load cost
regardless of conversation age.
Deduplicating would be the cheapest immediate win: the same payload is currently
written to disk twice per image, for no benefit I can observe.