[BUG] Chrome MCP screenshots accumulate in context, causing extreme token drain on session resume (17% of Max plan for 5 trivial turns)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

When using the Claude in Chrome extension (claude-in-chrome MCP), each computer screenshot action returns a base64-encoded JPEG image that gets permanently embedded in the conversation context. These images accumulate across the session and are re-sent to the API on every subsequent turn.

In a session with 18 screenshots (~1.7 MB of base64 data), resuming the next day and asking a simple question ("open the browser to our website and review the changes to the UI and layout") consumed 17% of my 5-hour Max plan usage in just 5 API calls. For comparison, an entirely separate conversation performing extensive code analysis with 10+ tool calls used only 1% of the same quota — a 17:1 cost ratio.

The user receives no warning that the context is bloated with old screenshot data. There is no crash or error — just silent, extreme token consumption.

What Should Happen?

1. Old screenshots should be evicted from context after a few turns (only the most recent 1-2 should be retained)
2. When resuming a session with accumulated image data, Claude Code should either prune the images or warn the user about the context cost
3. Screenshot data should not be re-sent in its entirety on every API call when it's no longer relevant to the current task

Error Messages/Logs

No errors or warnings are shown. The only symptom is rapid usage consumption visible on the account dashboard. The session transcript JSONL reveals the problem:

Session file: 54a680d7-1717-4e4e-a088-0030ac693b8c.jsonl
Total size: 2,736,990 bytes (2.7 MB)
Screenshot data: 1,746,937 bytes (1.7 MB) — 64% of session
Non-image data: 986,938 bytes (0.9 MB) — 36% of session

18 screenshots accumulated (42 KB to 291 KB each):
  Line 252:  42,957 bytes    Line 310:  52,565 bytes
  Line 259:  46,821 bytes    Line 322:  57,013 bytes
  Line 262:  44,517 bytes    Line 329:  51,109 bytes
  Line 265:  49,669 bytes    Line 344: 195,017 bytes
  Line 275:  41,653 bytes    Line 347: 147,135 bytes
  Line 278:  63,949 bytes    Line 351: 185,609 bytes
  Line 281:  64,653 bytes    Line 354: 151,463 bytes
  Line 293:  56,069 bytes    Line 388: 143,490 bytes
  Line 303:  55,485 bytes    Line 571: 297,763 bytes

Context at session resume: 2,419,821 bytes (2.3 MB)
Morning API calls: 5
Total input processed across 5 calls: ~12.1 MB
Estimated tokens per call: ~279,000 (vs ~20,000 for a fresh session = 13x overhead)

Steps to Reproduce

1. Start a Claude Code session with Chrome extension enabled (claude --chrome)
2. Perform browser work that involves multiple screenshots (e.g., navigating pages, checking layouts, debugging UI). Each computer action with screenshot adds a base64 image to context
3. After accumulating 10+ screenshots, end the session (rate limit, /exit, etc.)
4. Resume the session later with claude --continue
5. Ask any simple question that triggers a few API calls
6. Observe that usage consumption is dramatically disproportionate to the work being done

The critical factor is accumulation across turns — each new API call includes ALL previous screenshots in the context, not just the most recent one.

Claude Model

Opus

Is this a regression?

I don't know — anecdotally I have been using the Chrome extension on/off for the last few weeks and have not noticed this before, though it may be due to smaller session sizes.

Claude Code Version

2.1.50 (Claude Code)

Platform

Anthropic API (claude.ai Max subscription)

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Analysis

Each screenshot from the Chrome computer tool is stored as a base64 JPEG in the session JSONL transcript. The data is included in the message field as an image content block and duplicated in the toolUseResult field. When the session is resumed or a new turn begins, the full conversation history — including all accumulated screenshots — is sent to the API.

The cost compounds: turn N is more expensive than turn N-1 because the context has grown by the previous screenshot. In a session with 18 screenshots:

| Turn | Accumulated Context | Relative Cost vs Fresh Session |
|------|-------------------|-------------------------------|
| 1 (no screenshots) | ~20K tokens | 1x |
| After 5 screenshots | ~80K tokens | 4x |
| After 18 screenshots | ~279K tokens | 13x |
| Resumed next day (5 calls) | ~279K tokens x 5 | ~70x total |

Distinction from existing issues

• #20470 — Reports transcript files growing to 3.3 GB and causing crashes. Our case is different: the transcript is only 2.7 MB and no crash occurs. Instead, the failure mode is silent extreme token consumption with no user-facing indication.
• #9152 / #4002 — Reports single screenshots exceeding the 25K token MCP response limit. Our case is about cumulative accumulation of many screenshots that individually fit within limits but collectively dominate the context.
• #21230 — Reports context limit reached at 25% usage from a single Playwright screenshot. Related but different — our issue is about long-lived sessions where screenshots pile up and get re-sent on every turn.

Suggested fixes (in order of impact)

1. Evict old screenshots from context — Keep only the last 2-3 screenshots. Replace older ones with a text placeholder like [Screenshot from 2h ago — evicted to save context]
2. Warn on resume — When resuming a session containing >N MB of image data, warn the user and offer to start fresh
3. Deduplicate storage — The screenshot data appears twice in each JSONL entry (message.content[].source.data and toolUseResult.base64), doubling the on-disk size

Related issues

• #20470 (base64 transcript crash — OPEN)
• #9152 (single screenshot exceeds 25K token limit — closed as dup of #4002)
• #21230 (context limit at 25% from screenshot — closed as dup of #9152)
• #16856 (excessive token usage with MCP — OPEN)
• #27293 (feature request: lossless context cleanup before compaction — OPEN)