[BUG] Single ~60 MB file upload writes one oversized transcript entry; session then never loads (blank window, Windows desktop)

Preflight Checklist

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

What's Wrong?

What's Wrong?

Uploading a single large file (an OpenAPI/Swagger definition) into a Claude Code
desktop session wrote a ~60 MB single-line entry into the session transcript.
That one entry left the session permanently unopenable: the desktop app shows a
blank window and never finishes loading it.

Transcript: %USERPROFILE%.claude\projects<project><session-id>.jsonl
Size: 64,915 KB. Next-largest transcript in the same project: 517 KB.

Unlike #69009 (macOS, ~700 MB transcripts accumulated over months, hard V8 OOM
crash on launch), this was a single upload in one action at ~63 MB, and the
symptom is a hang rather than a crash — so the failure threshold is well below
what that report documents.

Three compounding problems:

1. No size guard at upload. The file is accepted, written to the transcript, and
   the session is unrecoverable from that point on.
2. The only remedy the app offers is compaction, which requires transmitting the
   oversized content. Resuming showed the "context window full" dialog; choosing
   the compact option crashed the session again.
3. The failure surfaces as a blank window with no error text, which points users
   toward reinstalling — useless here, since state lives in %USERPROFILE%.claude.

Claude Code Version

2.2553.1 (c38127)

Operating System

Windows 26100.9448

Additional Information

• Reinstalling the app has no effect, as transcripts are outside the app package.
• Related: #69009 (same underlying unbounded transcript growth, different OS,
  different failure mode, ~10x higher size threshold).

What Should Happen?

What Should Happen?

At minimum: an upload that would consume a large share of the context window
must not hang the app or leave the session unloadable. If the oversized entry
is already on disk, the session loader should skip or truncate it and surface
an error rather than showing a blank window.

Preferred: detect at upload time that the file will flood the context window,
say so, and offer to write it to disk instead of ingesting it — into the project
directory or the session's existing upload location — so Claude can read the
relevant ranges on demand. This is the workflow the documentation already
recommends for large files; the app should steer users into it rather than
letting the unusable path fail silently.

The threshold should be a share of the model's context window rather than a
fixed byte count, since context size varies by model.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

1. Open a Claude Code session in the desktop app on Windows.
2. Upload a single file of roughly 60 MB (mine was a JSON OpenAPI definition).
3. Session becomes unresponsive.
4. Reopen the app: blank window, no error, session never loads.
5. Confirmation: move the oversized .jsonl out of
   %USERPROFILE%.claude\projects<project>\ and relaunch — app works normally.
   Move it back — blank window returns.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.2553.1 (c38127)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

I had a lengthy discussion with Claude about what went wrong, and Claude provided most of the text I've submitted. But it's a serious problem. The fix on my end involves a bunch of CLI commands that I'm going to need to validate before I can even get back to work.

Reproduce the failure by uploading a roughly 60 MB OpenAPI JSON file, then inspect the resulting transcript at %USERPROFILE%.claude\projects<project><session-id>.jsonl and compare behavior with that file moved away. Done means the oversized upload does not leave the session unloadable, and an existing oversized transcript produces an error or safe recovery instead of a blank window.