[BUG] Claude-generated cron silently used a stale standalone CLI to resume an active VS Code session, repeatedly rebuilding ~760k-token cache

Preflight Checklist

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

What's Wrong?

Claude Code exhausted my entire five-hour Max session allowance in approximately ten minutes. Immediately before the limit was reached, two automated --resume requests rebuilt almost the entire prompt cache instead of reusing it:

• 12:10:22 EDT: 756,383 cache-creation tokens; 15,177 cache-read tokens; 618,127 missed input tokens.
• 12:15:18 EDT: 759,272 cache-creation tokens; 18,210 cache-read tokens; 624,108 missed input tokens.

Both requests reported cache_miss_reason: system_changed. At 12:15:24, only 5.7 seconds after the second rebuild, Claude Code returned error: rate_limit and said the session limit would reset at 5pm.

The requests came from a cron driver that Claude Code itself had designed and written when I asked it to keep working locally. The model hard-coded /home/USER/.local/bin/claude, which turned out to be a separate 2.1.207 CLI, while my active and user-maintained VS Code extension was 2.1.231. It told me the driver would continue "THIS exact session", but did not disclose that it was using a different, stale client.

Before creating the driver, Claude only ran which claude and a basic claude -p "Reply with exactly: HEADLESS-OK" check. It never ran claude --version, never tested the actual --resume command, and never tested concurrent access to the same session or its cache impact.

The cron invocations did not overlap each other because the generated script used flock, but they did overlap and interleave with the active VS Code session. I had only installed and maintained the VS Code extension; I did not knowingly select or configure the stale 2.1.207 client used by Claude's generated automation.

What Should Happen?

A second --resume from the same unchanged CLI environment five minutes later should reuse the stable cached prompt prefix.

If concurrently resuming a session that is active in VS Code cannot safely preserve the cache, Claude Code should warn, fork, or fail instead of silently rebuilding hundreds of thousands of cache tokens on every resume.

When Claude Code generates persistent automation that invokes claude, it should resolve the intended/current runtime, check and disclose its version, test the actual resume path, and warn before mixing a stale standalone CLI with an active VS Code session. It should not tell the user this safely continues the "exact session" when that path has not been tested.

Error Messages/Logs

2026-08-14T16:10:22.485Z
entrypoint=sdk-cli version=2.1.207 model=claude-fable-5
cache_creation_input_tokens=756383
cache_read_input_tokens=15177
cache_creation.ephemeral_1h_input_tokens=756383
cache_creation.ephemeral_5m_input_tokens=0
diagnostics.cache_miss_reason.type=system_changed
diagnostics.cache_miss_reason.cache_missed_input_tokens=618127

2026-08-14T16:15:18.671Z
entrypoint=sdk-cli version=2.1.207 model=claude-fable-5
cache_creation_input_tokens=759272
cache_read_input_tokens=18210
cache_creation.ephemeral_1h_input_tokens=759272
cache_creation.ephemeral_5m_input_tokens=0
diagnostics.cache_miss_reason.type=system_changed
diagnostics.cache_miss_reason.cache_missed_input_tokens=624108

2026-08-14T16:15:24.409Z
entrypoint=sdk-cli version=2.1.207
error=rate_limit
message="You've hit your session limit; resets 5pm (America/New_York)"

Steps to Reproduce

This is the exact incident sequence. I have not rerun it in a controlled test because repeating two full cache rebuilds on the original session could consume another Max usage window.

1. Install and use the current Claude Code VS Code extension on Ubuntu; continue a large existing session.
2. Ask Claude Code to create a local recurring wake mechanism that continues the same session after VS Code closes.
3. In this incident, Claude Code itself found /home/USER/.local/bin/claude, performed only a basic claude -p test, wrote a cron driver that hard-coded that binary, and then changed it to use -p --resume SESSION_ID.
4. Add the generated driver to cron as instructed by Claude Code.
5. Leave the same session active in VS Code when the cron driver fires.
6. Let the generated non-interactive command fire twice within five minutes.
7. Inspect the session JSONL and group assistant records by requestId, because one response may be stored as multiple content-block records.
8. Compare message.usage.cache_creation_input_tokens, message.usage.cache_read_input_tokens, and message.diagnostics.cache_miss_reason on the first request from each standalone process.

In the incident, the user-maintained VS Code client was 2.1.231 and the undisclosed standalone binary selected by Claude's generated script was 2.1.207. Both resumed requests returned system_changed and created about 760k one-hour-cache tokens.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.231 (user-installed active VS Code extension; now updated to 2.1.232). Claude-generated script silently invoked separate 2.1.207 standalone CLI.

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

Environment:

• Ubuntu 20.04.6 LTS, Linux x86_64
• Claude.ai Max subscription
• I only knowingly installed and maintained the VS Code extension. I did not knowingly select or configure the 2.1.207 standalone CLI.
• Service tier recorded in transcript: standard
• Effort: high
• Time zone: America/New_York (EDT)

Claude Code's own setup actions recorded in the transcript:

• 00:17:55 EDT, VS Code 2.1.231: ran which claude, checked crontab, and ran only timeout 120 claude -p "Reply with exactly: HEADLESS-OK".
• It did not run claude --version or test --resume.
• 00:18:16: wrote runs/loop_driver.sh, hard-coding /home/USER/.local/bin/claude.
• 00:18:59: edited that script to add --resume with the live VS Code session ID.
• It told me: "The driver now uses --resume with THIS session's ID, so every wake continues this exact conversation."
• It later instructed me to add the generated script to cron. It did not disclose that this was a separate 2.1.207 client or warn about concurrent access to the active VS Code session.

Evidence and controls:

• Main-session 12:06–12:16 window, de-duplicated by requestId: 40 requests, 28,723,803 cache reads, 2,280,753 cache creations, and 16,918 output tokens.
• Fixed 03:05–03:15 UTC control window: 50 requests, 35,342,808 cache reads, only 27,693 cache creations, and 16,063 output tokens.
• The incident therefore had fewer requests and similar output, but about 82x more cache creation.
• The same session previously resumed after gaps as long as 350 hours and had individual cold creations up to 960,997 tokens without this immediate exhaustion pattern. The long pause can explain the initial VS Code cold load, but not two additional full CLI rebuilds five minutes apart.
• The JSONL parses successfully, relevant parent UUIDs exist, and totals are grouped by requestId.

The five startup attachment objects from the 12:10 and 12:15 standalone invocations were serialized with jq -cS and SHA-256 hashed. Every corresponding pair was identical: deferred_tools_delta, agent_listing_delta, skill_listing, task_reminder, and command_permissions. The second resume nevertheless reported system_changed again. The actual serialized API system/tools arrays are not present in the transcript, so an unlogged schema or ordering difference remains possible.

Most likely trigger:
Claude Code-generated automation attached an undisclosed stale standalone sdk-cli to a session concurrently active in the current VS Code extension. The clients had different versions and possibly different system/tool schemas. I can prove the model-generated setup, repeated full cache invalidation, and timing, but not Anthropic's private Max quota calculation.

Possibly related:

• https://github.com/anthropics/claude-code/issues/42338
• https://github.com/anthropics/claude-code/issues/34629
• https://github.com/anthropics/claude-code/issues/63930

Claude Code's changelog says 2.1.90 fixed a --resume full prompt-cache miss involving deferred tools, MCP servers, or custom agents. This may be a remaining concurrent/mixed-entrypoint variant. Exact request IDs and the private transcript are available to Anthropic support but intentionally omitted here.