[Claude Code] Repeated context injection via JSONL attachments causes linear token bloat across long sessions

Where to submit: https://github.com/anthropics/claude-code/issues Label suggestion: bug, performance, context-management

Summary

Claude Code persists every hook result, built-in task_reminder, IDE events, skill-list changes, tool-call side-events, subagent progress, and last-prompt as separate attachment / last-prompt / progress entries in the session JSONL under <USER_HOME>/.claude/projects/<PROJECT_ID>/<SESSION_ID>.jsonl. On every subsequent API turn, history reconstruction re-includes these entries in the prompt payload, so the same content is re-transmitted many times within one session, producing linear token bloat that users perceive as "the same context being injected on every turn."

In a 150-minute live monitoring window across five concurrent sessions, this report documents:

• Linear, unbounded growth of per-turn API payload (~1,100 tokens/min) in a continuously-used session, reaching 661,706 tokens = 66% of a 1 M-token context window in 148 minutes.
• Auto-compaction is observable but does not help: three spikes of cache_creation_input_tokens at 455K~558K each, immediately followed by cache_read returning to its pre-compaction 500K level.
• /clear is a temporary reset, not a fix: 319 reset events were logged across four sessions; every reset was followed by rapid re-accumulation.
• Per-tool-use fan-out: one Bash call produces ~3 attachment/hook_success entries.
• Subagent silos: Agent / Task invocations create separate JSONLs of up to 6.4 MB each, on top of the main session.
• Global CLI history (<USER_HOME>/.claude/history.jsonl) retains every input across all sessions/projects forever with no documented purge command.

All findings are reproducible across concurrent sessions on the same machine and persist after upgrading to the latest Claude Code v2.1.113.

Environment

Same sessionId is reused across CLI restarts and version upgrades, so accumulated attachment / last-prompt entries carry over — a restart does not reset the re-injection problem.

Reproduction

Any long-running session reproduces this. Below are five concurrent sessions on the same machine; all show the same structural pattern.

session       size        attachment   task_reminder   last-prompt
-------       ----        ----------   -------------   -----------
<PROJECT_A>   2.2 MB          532            16             54
<PROJECT_B>   2.5 MB          429            14             62
<PROJECT_C>   7.2 MB        1,413            32            168
<PROJECT_D>   3.4 MB          992            11             81
<PROJECT_E>   870 KB          154             9             20

Minimal steps to reproduce:

1. Start a Claude Code session in any project.
2. Use tools (Bash/Edit/Write/Read) and invoke skills/agents for 30+ turns.
3. Inspect <USER_HOME>/.claude/projects/<PROJECT_ID>/<SESSION_ID>.jsonl.
4. Observe the entry-type distribution and repeated content.

Evidence

1. Entry-type distribution in a 7.2 MB session (<PROJECT_C>)

entry type              count    bytes        %
attachment              1,413    1.66 MB     22%
assistant                 860    1.79 MB     25%
user                      684    2.71 MB     37%
permission-mode           176       20 KB     0%
last-prompt               168       26 KB     0%
file-history-snapshot      97      297 KB     4%
custom-title               84        9 KB     0%
agent-name                 84        9 KB     0%
system                     66       52 KB     1%
queue-operation            11        2 KB     0%

attachment alone is 22% of the JSONL. Combined with last-prompt and file-history-snapshot, Claude-Code-generated metadata exceeds 26% of persisted session bytes.

2. Repeated attachment content — hash-based duplication analysis

hash            repeats   size/copy   cumulative waste
<HASH_1>          16 ×     56 B          896 B    task_reminder itemCount=0 (empty list)
<HASH_2>           9 ×     51 B          459 B
<HASH_3>           5 ×  8,730 B       43,650 B    (large repeated payload)
<HASH_4>           5 ×  2,931 B       14,655 B
<HASH_5>           5 ×    456 B        2,280 B    specific task object persisted 5×
<HASH_6>           3 ×  1,396 B        4,188 B    specific task object persisted 3×

• Total attachment bytes: ~1.72 MB
• After content-hash deduplication: ~1.56 MB
• Bytes wasted on duplicates in storage alone: ~154 KB (~9%)

That 9% is storage only. The amplification is in the API payload: each past attachment is re-included on every subsequent API turn, so one duplicate attachment in storage becomes duplicate re-transmission on every future turn.

3. attachment.type catalog — not just hook output

Live observation on v2.1.113 shows Claude Code persists at least nine distinct attachment types, covering almost every in-session state change:

attachment.type           role
------------------------  -----------------------------------------------------
hook_success              user + plugin hook results (dominant, 89 / 300 entries in sample)
task_reminder             built-in TodoWrite nag
opened_file_in_ide        IDE file-open tracking
deferred_tools_delta      tool list updates
skill_listing             skill list snapshot
command_permissions       permission mode changes
date_change               system clock date rollover
hook_non_blocking_error   hook execution failures
hook_additional_context   hook-injected additionalContext
hook_system_message       hook-emitted system messages

Every one of these is persisted as a separate JSONL entry and is a candidate for re-injection on subsequent turns.

4. task_reminder is emitted by Claude Code itself (not user hooks)

itemCount distribution (<PROJECT_C> session):
  0: 16   ← "task tools haven't been used recently" reminder
  1:  5
  3:  3
  4:  5
  7:  1
 10:  1
 13:  1

The itemCount: 0 variant is the built-in <system-reminder>The task tools haven't been used recently. If you're working on tasks that would benefit from tracking progress, consider using TaskCreate ...</system-reminder> nag. It is stored as a separate attachment entry sixteen times in one session. A built-in Claude Code reminder is a primary contributor — user plugins/hooks are not the cause.

5. last-prompt entries duplicate user input

total last-prompt entries:  168
unique content hashes:       22
mean copies per unique:    7.6 ×

The same user prompt string is persisted up to 16 times per session. A 2 KB user message therefore occupies up to 32 KB of JSONL through this mechanism alone — before considering its inclusion in subsequent API payloads.

6. <system-reminder> tags are not stored in the user-message body

When parsing message.content[].text for type: user entries specifically, zero <system-reminder> tags are found in the <PROJECT_C> session, even though those tags appear in the live prompt. This proves:

• <system-reminder> blocks are runtime-injected during API payload construction, not persisted.
• The persistence that causes bloat is not the reminders themselves — it is the attachment / last-prompt entries that Claude Code reads back in and re-attaches on every turn.

7. Cross-session confirmation rules out user-side causes

The 5 sessions above are in 5 different projects with different CLAUDE.md, different plugin activity, and different workflows. All show the same attachment / task_reminder / last-prompt accumulation pattern. This is a Claude Code binary behavior, not a user misconfiguration.

8. Direct API-payload evidence — usage fields returned by Anthropic API

The message.usage object in each assistant entry is server-returned and non-forgeable. It reports the exact token counts Anthropic's API billed for the preceding request. Plotting these across a session shows the payload growth directly.

session       turns   first-turn     25%       50%       75%      last-turn
-------       -----   ----------   -------   -------   -------   ---------
<PROJECT_C>     860       52,572    80,656   152,242   285,677     498,255
<PROJECT_B>     390       86,804   189,077   349,696   422,434     497,299
<PROJECT_D>     530       89,619   185,527   251,836   343,565     431,287
<PROJECT_E>     105       92,183   134,735   168,584   198,054     242,501

Last-turn breakdown:

session       input   cache_read   cache_creation   output     TOTAL
-------       -----   ----------   --------------   ------    --------
<PROJECT_C>       1      497,533              721    1,662     498,255
<PROJECT_B>       1      496,604              694    1,123     497,299
<PROJECT_D>       1      430,331              955    1,274     431,287
<PROJECT_E>       6      231,371           11,124    3,200     242,501

Key observations:

• input_tokens is 1~6 across every sampled last turn — essentially no "genuinely new" content is sent raw.
• cache_read_input_tokens carries 231K~497K — the entire conversation (including every historical attachment, tool_result, last-prompt, assistant output) is re-included in every request via prompt cache.
• cache_creation_input_tokens = 721~11,124 per turn — this is the increment appended to cache each turn, which then compounds into the next turn's cache_read.
• Growth is approximately linear in turn count: <PROJECT_C> sampled at turns 0 / 215 / 430 / 645 / 859 yields 52K / 80K / 152K / 285K / 498K, averaging ~540 tokens of permanent context growth per turn.
• <PROJECT_C>'s last turn occupies 49.8% of the 1M-token context window before any new user input. Earlier turns in that same session fit comfortably — the growth is structural, not driven by user content.

9. Mapping cache growth back to attachment accumulation

From the attachment analysis above, <PROJECT_C> contains ~1.72 MB of attachment bytes across 1,413 attachment entries, averaging 1.2 KB per attachment ≈ 300 tokens**. The per-turn cache_creation_input_tokens range of 72111,124 observed in §8 corresponds to **roughly 236 attachment-equivalents per turn being appended to the running context.

This is the arithmetic bridge between §2~§5 (what gets persisted in JSONL) and §8 (what actually gets billed in the API request). It confirms the originally-hypothesized mechanism: Claude Code stores per-turn events as attachments in JSONL, then re-sends them on every subsequent API call via the prompt cache, and the cache size — and therefore per-turn billable tokens — grows linearly with the number of turns.

10. Idle Claude Code still accumulates JSONL — /clear with zero user input

Starting Claude Code v2.1.113 and immediately pressing /clear twice, with zero user text input, produces a micro-session whose JSONL already contains seven entries totalling ~3.9 KB:

entry 0  file-history-snapshot     (auto-generated by Claude Code, no timestamp)
entry 1  attachment/hook_success          hookName = SessionStart:clear
entry 2  attachment/hook_system_message   hookName = SessionStart:clear  content = "bkit v2.1.7"
entry 3  attachment/hook_success          hookName = SessionStart:clear
entry 4  user        <local-command-caveat>…</local-command-caveat>
entry 5  user        <command-name>/clear</command-name>…
entry 6  system/local_command             (empty stdout)

Observations:

• /clear re-fires SessionStart hooks — matcher name observed is literally SessionStart:clear. Every SessionStart-bound hook (user and plugin) emits a fresh attachment entry, even though the user did not start a new session deliberately.
• User-typed bytes: 0. Persisted JSONL bytes: 3,941. Every byte of the JSONL is eligible for re-inclusion in the next API request.
• A user who never types anything, only presses /clear, still pays the cache-creation tax for these attachments.

This rules out "the user is accumulating context" as a possible cause. The accumulation happens purely from Claude Code's own lifecycle events.

11. v2.1.113 upgrade does not fix the issue

Same sessions analyzed before and after auto-upgrade, splitting entries by the version field they were written under:

session       version    entries   attach   tr:itemCount=0   last-p(unique)
--------      -------    -------   ------   --------------   --------------
<PROJECT_C>    2.1.110     1,937      945          16             —
<PROJECT_C>    2.1.112       522      189           0             —
<PROJECT_C>    2.1.113       533      279           0         168 (22 uniq, 7.6×)
<PROJECT_E>    2.1.112       288      136           5             —
<PROJECT_E>    2.1.113        23        9           0          20 ( 8 uniq, 2.5×)
<PROJECT_D>    2.1.112     1,546      793           4             —
<PROJECT_D>    2.1.113       369      199           7          81 (11 uniq, 7.4×)
<PROJECT_B>    2.1.112       714      249           1             —
<PROJECT_B>    2.1.113       395      187           1          63 ( 8 uniq, 7.9×)

Readings:

• attachment / entries ratio on v2.1.113 is 40~54% — equal to or worse than older versions.
• task_reminder itemCount=0 emission on v2.1.113: decreases in some sessions, increases in others — the patch is not a coalescing fix; it is situational.
• last-prompt continues to persist ~7× copies of each unique prompt on v2.1.113 (no improvement).
• CLI restart keeps the same sessionId and writes to the same JSONL — prior accumulation carries over and is re-included in future API payloads.

v2.1.113 does not address the root cause.

12. Tool-use amplification — one Bash call produces ~3 attachment entries

Inspecting the last 12 entries written during an active turn of this reporting session shows a repeating motif. One Bash invocation expands into one tool_use / tool_result pair plus three attachment/hook_success entries (one PreToolUse + another PreToolUse variant + one PostToolUse). A typical slice:

[user-input]
file-history-snapshot                      (auto-generated by Claude Code)
assistant: thinking
assistant: tool_use                         ← Bash call #1
attachment/hook_success                     ← PreToolUse:Bash hook
attachment/hook_success                     ← PreToolUse:Bash hook (second)
user: tool_result
attachment/hook_success                     ← PostToolUse:Bash hook
assistant: thinking
assistant: text
assistant: tool_use                         ← Bash call #2
...

Implication: every tool use, regardless of content, appends three attachment entries to the JSONL. Ten Bash invocations → 30 new attachments. Given §9's conversion of ~300 tokens per attachment, this is ~9K tokens per 10 tool calls purely from hook-success persistence, all of which re-enter subsequent turns' prompt caches.

13. Subagent JSONL silos — parallel accumulation under subagents/

Agent / Task tool invocations create a separate JSONL per subagent under <PROJECT_ROOT>/subagents/agent-*.jsonl. These exhibit the same attachment accumulation pattern as the parent session, compounding the problem.

total subagent JSONL files on machine : 1,091
largest single subagent JSONL         : 6,378,381 B (6.4 MB)
largest subagent internal composition : progress 2,615  assistant 163  user 97  system 9

The progress entry type appears only in subagent JSONLs — one per step of the subagent's execution — and each carries its own persisted state. A single 6.4 MB subagent JSONL is comparable in size to a large main session, and every parent-session turn that invoked a subagent pays both costs.

14. Global CLI history file never rotates

<USER_HOME>/.claude/history.jsonl stores every command-line input typed into Claude Code across all sessions and all projects on the machine, forever.

<USER_HOME>/.claude/history.jsonl   846,561 B
lines                               2,674
schema                              {display, pastedContents, project, sessionId, timestamp}
sample display values               "/exit", "/clear", <free-form user prompts>

Unlike session JSONLs, this file is not re-injected into API requests, so it does not contribute to per-turn token bloat. However:

• It accumulates without bound; /clear does not touch it.
• It preserves every prompt a user typed — which for security-sensitive users can include paths, API keys, database URLs that were pasted on the CLI.
• There is no documented mechanism to rotate or purge it.

This is a separate issue in spirit (privacy / data retention rather than per-turn cost), but it shares the root cause pattern: Claude Code persists everything and provides no user-level trimming controls.

15. 150-minute continuous live monitoring — linear growth, auto-compaction inefficacy, /clear is temporary

A persistent monitor snapshotted five active sessions every 30 seconds from 09:22 to 12:00 local time (316 log lines, 314 snapshots). Full per-session findings:

15.1 Longest continuously-used session: <PROJECT_C> (148 min, 230 snapshots, zero /clear)

elapsed    size          total_tokens   cache_r      cache_c      input
-------    ------------  ------------   ----------   ---------    -----
  0m        7,273,633        498,255       497,533         721        1
 10m        7,300,616        500,013        44,488     455,519        6   ← auto-compaction
 20m        7,524,612        524,962       522,689       2,272        1
 60m        8,092,572        582,403        44,488     537,909        6   ← auto-compaction
 70m        8,293,253        602,914        44,488     558,420        6   ← auto-compaction
120m        8,606,324        638,367       637,545         821        1
140m        8,850,869        661,706       661,594         111        1
148m        8,850,869        661,706       661,594         111        1  (final)

148 min Δ:  size +1.58 MB  /  tokens +163,451  (≈ 1,100 tokens/min, linear)
peak:       661,706 tokens = 66% of a 1 M-token context window

The user performed normal work in this session; no /clear or /compact commands were issued. Per-turn input_tokens stayed at 1~6 throughout, confirming that growth is driven by Claude-Code-persisted state, not by user text.

15.2 Auto-compaction is observed — and does not help

At the 10 min, 60 min, and 70 min marks, cache_read_input_tokens collapses from 500 K to 44,488 while cache_creation_input_tokens spikes to **455 K558 K** in the same turn. This is the observable signature of prompt-cache reconstruction / auto-compaction.

time    cache_r before   cache_r after   cache_c (that turn)   billable amplification
-----   --------------   -------------   -------------------   -------------------------
 10m         497,533          44,488            455,519        cache_c billed at 125% of input
 60m          ~538,000         44,488            537,909         equivalent to ~672 K input tokens
 70m          ~558,000         44,488            558,420         equivalent to ~698 K input tokens

Yet the very next snapshot after each compaction event shows cache_r back in the 500 K range. Auto-compaction does not reduce the context that subsequent turns have to carry — it rebuilds the cache from that same context and immediately resumes accumulation. In effect the user pays a cache-creation surcharge and the new cache starts filling back up at the same rate.

15.3 /clear is reset, not a fix — five-session reset tally

session              snapshots   reset events   peak tokens   final tokens
---------------      ---------   ------------   -----------   ------------
<PROJECT_C>             230             0         661,706        661,706   (monotonic)
<PROJECT_A>              411           103         266,927        266,927   (final re-accumulation to peak)
<PROJECT_B>              502           211         562,491              0   (ended in /clear state)
<PROJECT_D>              213             1         558,418              0   (single late reset)
<PROJECT_E> (this session)   173             4         290,986         89,945   (repeated reset / accumulate)

A "reset event" is detected when last_total_tokens falls to less than 50 % of the previous snapshot's value with the previous value > 50 K.

Readings:

• The only session that avoided resets is the one where the user never ran /clear. It is also the one that reached 66 % of the 1 M window.
• <PROJECT_B> and <PROJECT_A> users /clear-ed many times (211 and 103 resets). After each reset, the session re-accumulated within minutes. <PROJECT_A> eventually reached 266 K tokens at the 110-min mark despite heavy /clear use.
• Resetting is a perpetual cost — users are effectively paying for context they throw away because they cannot selectively prune persisted attachments.

15.4 Aggregate over 150 min

total snapshots across 5 sessions             : 1,529
combined JSONL size change in 150 min         : +0.65 MB net (with four sessions resetting)
longest uninterrupted accumulation            : 148 min → +163 K tokens linear
largest peak observed                         : 661,706 tokens (66 % of 1 M window)
auto-compaction events observed in one session: 3
total /clear-induced resets observed          : 319 across 4 sessions

Expected vs Actual

Expected

• History reconstruction sends past turns without re-attaching transient metadata that is already summarized in the current turn.
• Built-in nags (task_reminder with itemCount: 0) emit at most once per threshold condition, not per tool call.
• last-prompt is a pointer, not a full-content copy on every write.
• Restarting the CLI, auto-updating, or idling resets ephemeral attachment accumulation.
• Auto-compaction meaningfully reduces the persisted context a subsequent turn must carry.
• Subagents (Agent / Task) run in an isolated context that does not compound main-session cost.
• One tool call produces roughly one persisted event.

Actual

• Each past attachment is re-included on every API turn → payload grows linearly with turn count (§8, §15.1).
• task_reminder itemCount:0 is appended on nearly every tool use where TodoWrite is not active → users pay for the same nag 16+ times per session (§4).
• last-prompt duplicates the prompt string ~7-8× on average (§5).
• Restart keeps the same sessionId and all accumulated attachments; idle sessions still accumulate when /clear is pressed (§7, §10).
• Auto-compaction was observed three times in one 148-min session (§15.2). Each event spikes cache_creation by 455K~558K tokens (billed at 125% of input), and the immediately following turn's cache_read returns to the same pre-compaction level — compaction is billed but does not shrink ongoing per-turn payload.
• Subagent Task calls create independent JSONLs under subagents/agent-*.jsonl that reach 6.4 MB each and repeat the same attachment accumulation pattern (§13).
• One Bash tool call produces roughly three attachment/hook_success entries (§12).

Impact

• Cost: API token consumption grows faster than the information content of the conversation. 5-minute prompt-cache TTL does not absorb this because session JSONL entries change on every turn, invalidating cache boundaries downstream of the first modification. In a 148-minute continuously-used session, the per-turn API payload grew linearly by ~1,100 tokens/min and reached 661,706 tokens — 66% of a 1M-token context window (§15.1).
• Latency: Larger payloads → slower first-token time and slower auto-compaction triggers. Auto-compaction itself introduces 455K~558K-token spikes (§15.2).
• Context window: Usable context shrinks faster than the visible conversation warrants, forcing premature /clear or /compact. Heavy /clear users were observed resetting 211 times in a single session (<PROJECT_B>, §15.3) without ever escaping re-accumulation; the user who never /clear-ed hit 66% of the 1M window.
• User experience: Users perceive "the same context injected repeatedly" without a clear mitigation path because the cause is internal and survives restarts, upgrades, /clear, and /compact.
• Privacy (secondary): <USER_HOME>/.claude/history.jsonl retains every CLI input across all projects forever, with no documented purge command (§14).

Requested

One or more of:

1. Deduplicate attachment entries by content hash before including them in API payload history reconstruction.
2. Coalesce task_reminder — emit at most once per N turns or once per distinct itemCount change, and suppress the itemCount: 0 variant beyond the first occurrence.
3. Trim last-prompt storage — store a reference/hash once rather than a full copy on each submit.
4. Collapse skill_listing / deferred_tools_delta / command_permissions — only persist deltas that actually change state.
5. Reduce per-tool-use attachment fan-out — one hook_success per tool call is enough; the current ~3 (PreToolUse × 2 + PostToolUse) multiplies cost for every Bash/Edit/Write.
6. Stop re-injecting subagent progress entries during main-session history reconstruction; subagent JSONLs already contain the full trace.
7. Make auto-compaction actually lossy — after a cache_creation spike of the entire conversation, discard or summarize the next turn's persisted history rather than immediately letting cache_read return to the same pre-compaction level.
8. Expose a user-level setting (e.g. settings.json → experimental.historyCompaction: true) so power users can opt into aggressive attachment compression.
9. Offer a /clear-attachments command that strips non-essential attachment types from the current JSONL in place, without ending the session.
10. Rotate or cap <USER_HOME>/.claude/history.jsonl — right now it stores every CLI input across all projects forever, including pasted secrets.
11. Document the current injection semantics in the Hooks / Context Management section so users can audit their own sessions with confidence.

Workarounds the user tried (limited effect)

• Removing dormant UserPromptSubmit hooks (prd-detector, skill-router, disabled-plugin leftovers) slightly reduces attachment creation rate.
• Using TodoWrite eagerly prevents the itemCount: 0 task_reminder from firing.
• Running /clear resets JSONL entry count but loses context. In the 150-min monitoring window, 319 /clear resets were observed across 4 sessions, each followed by rapid re-accumulation — never a durable fix.
• Running /compact or waiting for auto-compaction: observed three times in one 148-min session; each event spikes cache_creation by 455 K~558 K tokens (billed at 125% of input), and the very next turn's cache_read is back in the 500 K range — compaction is billed but does not meaningfully shrink the ongoing per-turn payload.
• Uninstalling unused plugins reduces hook fan-out.
• Avoiding Agent/Task tool use avoids creating subagent JSONL silos, but at the cost of losing parallelism.
• Upgrading to v2.1.113 — no material change.

None address the underlying re-injection on every turn.

Reproduction artifacts

JSONL files referenced above (paths redacted):

<USER_HOME>/.claude/projects/<PROJECT_A>/<SESSION_ID_A>.jsonl  (2.2 MB)
<USER_HOME>/.claude/projects/<PROJECT_B>/<SESSION_ID_B>.jsonl  (2.5 MB)
<USER_HOME>/.claude/projects/<PROJECT_C>/<SESSION_ID_C>.jsonl  (7.2~8.9 MB, grew during monitoring)
<USER_HOME>/.claude/projects/<PROJECT_D>/<SESSION_ID_D>.jsonl  (3.4~4.6 MB)
<USER_HOME>/.claude/projects/<PROJECT_E>/<SESSION_ID_E>.jsonl  (0.1~1.2 MB, reset during monitoring)
<USER_HOME>/.claude/projects/<PROJECT_*>/subagents/agent-*.jsonl   (1,091 files machine-wide, largest 6.4 MB)
<USER_HOME>/.claude/history.jsonl                               (846,561 B, 2,674 entries, machine-wide)

Live-monitoring artifact:

<USER_HOME>/.claude/plugins/…/monitor.log    (JSON Lines, 314 snapshots at 30 s intervals,
                                              09:22–12:00 local time, 321 KB)

Schema of one monitor.log snapshot:

{
  "ts": "2026-04-20T11:48:32",
  "sessions": [
    {
      "session": "<PROJECT_C>",
      "size": 8850869,
      "mtime_ago_s": 4,
      "last_total_tokens": 661706,
      "last_input": 1,
      "last_cache_r": 661594,
      "last_cache_c": 111,
      "last_out": 1662,
      "last_version": "2.1.113"
    }
  ]
}

The numeric tables in §Evidence can be regenerated by (a) counting "type":"attachment", "task_reminder", "type":"last-prompt" occurrences in the JSONLs, (b) hashing attachment payloads for dedup counts, or (c) replaying the monitor.log to reconstruct the per-session time series.

Checklist before submission

• Run one of the above JSONL files through the Python snippet in §Reference below and paste the output into the GitHub issue.
• Attach (or link) a sanitized JSONL excerpt of a repeated-attachment block.
• Confirm Claude Code version with claude --version and paste the exact string.
• If possible, include /cost output from a session that hit the problem.
• Optionally run the live-monitor script (§Monitor Script) for 30+ min in an active session and attach its monitor.log.
• Redact any proprietary project names from the JSONL and from the paths before attaching.
• Redact any personally-identifying strings from <USER_HOME>/.claude/history.jsonl if referenced.

Reference snippet for reproducing the numbers

# Usage: python this_script.py <USER_HOME>/.claude/projects/<PROJECT_ID>/<SESSION_ID>.jsonl
import json, hashlib, collections, sys

path = sys.argv[1]
counts = collections.Counter()
hashes = collections.Counter()
task_reminder_items = collections.Counter()
attachment_types = collections.Counter()
version_split = collections.defaultdict(lambda: {'entries':0, 'attach':0, 'tr0':0, 'lp':0})
last_prompt_hashes = set()
last_prompts = 0

with open(path, 'r', encoding='utf-8') as f:
    for line in f:
        try:
            d = json.loads(line)
        except Exception:
            continue
        t = d.get('type', '')
        v = d.get('version', 'unknown')
        counts[t] += 1
        version_split[v]['entries'] += 1
        if t == 'attachment':
            version_split[v]['attach'] += 1
            att = d.get('attachment', {})
            attachment_types[att.get('type', '?')] += 1
            h = hashlib.md5(json.dumps(att, sort_keys=True).encode()).hexdigest()[:12]
            hashes[h] += 1
            if att.get('type') == 'task_reminder':
                ic = att.get('itemCount', -1)
                task_reminder_items[ic] += 1
                if ic == 0:
                    version_split[v]['tr0'] += 1
        elif t == 'last-prompt':
            last_prompts += 1
            version_split[v]['lp'] += 1
            last_prompt_hashes.add(hashlib.md5(d.get('lastPrompt', '').encode()).hexdigest()[:12])

print('entry type counts           :', dict(counts))
print('attachment.type catalog     :', dict(attachment_types))
print('top repeated attachment     :', hashes.most_common(10))
print('task_reminder itemCount dist:', dict(task_reminder_items))
print(f'last-prompt: {last_prompts} entries, {len(last_prompt_hashes)} unique')
print('by version                  :', dict(version_split))

Monitor Script — capture live per-turn growth

Save as monitor.py and run in the background (python monitor.py &). Writes one JSON line per snapshot every 30 seconds.

"""
Snapshot every 30 s until today's 12:00 local. Logs size + last assistant usage
(input / cache_read / cache_creation / output) for every session JSONL modified
within the last 10 minutes. One JSON line per snapshot appended to monitor.log.
"""
import json, os, glob, time, datetime

HERE = os.path.dirname(os.path.abspath(__file__))
LOG = os.path.join(HERE, 'monitor.log')
PROJECTS_ROOT = os.path.expanduser('~/.claude/projects')


def last_assistant_usage(path):
    try:
        last = None
        with open(path, 'r', encoding='utf-8') as f:
            for line in f:
                try:
                    d = json.loads(line)
                except Exception:
                    continue
                if d.get('type') == 'assistant' and d.get('message', {}).get('usage'):
                    last = d
        if not last:
            return None
        u = last['message']['usage']
        return {
            'v': last.get('version', ''),
            'in': u.get('input_tokens', 0),
            'cache_r': u.get('cache_read_input_tokens', 0),
            'cache_c': u.get('cache_creation_input_tokens', 0),
            'out': u.get('output_tokens', 0),
        }
    except Exception:
        return None


def snapshot():
    now = time.time()
    files = glob.glob(os.path.join(PROJECTS_ROOT, '**', '*.jsonl'), recursive=True)
    active = []
    for f in files:
        try:
            mt = os.path.getmtime(f)
            sz = os.path.getsize(f)
        except OSError:
            continue
        if now - mt < 600:
            active.append((f, mt, sz))
    active.sort(key=lambda x: -x[1])
    sessions = []
    for f, mt, sz in active[:8]:
        u = last_assistant_usage(f) or {}
        total = u.get('in', 0) + u.get('cache_r', 0) + u.get('cache_c', 0)
        rel = f[len(PROJECTS_ROOT):]
        for ch in ('/', os.sep):
            rel = rel.lstrip(ch)
        label = rel
        for ch in ('/', os.sep):
            if ch in label:
                label = label.split(ch, 1)[0]
                break
        sessions.append({
            'session': label, 'size': sz, 'mtime_ago_s': int(now - mt),
            'last_total_tokens': total,
            'last_input': u.get('in', 0),
            'last_cache_r': u.get('cache_r', 0),
            'last_cache_c': u.get('cache_c', 0),
            'last_out': u.get('out', 0),
            'last_version': u.get('v', ''),
        })
    return {
        'ts': datetime.datetime.now().isoformat(timespec='seconds'),
        'sessions': sessions,
    }


def main():
    now = datetime.datetime.now()
    end = datetime.datetime.combine(now.date(), datetime.time(12, 0, 0))
    if end <= now:
        end = end + datetime.timedelta(days=1)
    with open(LOG, 'a', encoding='utf-8') as fp:
        fp.write(json.dumps({'ts': now.isoformat(timespec='seconds'), 'event': 'monitor_start',
                             'end_target': end.isoformat(timespec='seconds')}) + '\n')
        fp.flush()
        while datetime.datetime.now() < end:
            fp.write(json.dumps(snapshot(), ensure_ascii=False) + '\n')
            fp.flush()
            time.sleep(30)
        fp.write(json.dumps({'ts': datetime.datetime.now().isoformat(timespec='seconds'),
                             'event': 'monitor_end'}) + '\n')


if __name__ == '__main__':
    main()

Post-processing (time-series and reset detection):

import json, time
p = 'monitor.log'
snaps = [json.loads(l) for l in open(p, encoding='utf-8') if l.strip() and 'sessions' in l]
def e(ts): return time.mktime(time.strptime(ts, '%Y-%m-%dT%H:%M:%S'))
series = {}
for s in snaps:
    for ses in s['sessions']:
        series.setdefault(ses['session'], []).append((e(s['ts']), ses['size'],
                                                      ses['last_total_tokens'],
                                                      ses['last_cache_r'],
                                                      ses['last_cache_c']))
for name, rec in series.items():
    resets = sum(1 for i in range(1, len(rec))
                 if rec[i-1][2] > 50000 and rec[i][2] < rec[i-1][2] * 0.5)
    peak = max(rec, key=lambda r: r[2])
    print(f'{name}: snaps={len(rec)} resets={resets} peak_tokens={peak[2]}')