[BUG] Claude Code enters metadata-regeneration loop on long sessions, sustained 100%+ CPU after conversation ends

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?

After an extended productive Claude Code session via the VS Code Remote-SSH extension to a Linux HPC login node (~7 hours, 782 user/assistant conversation entries, session JSONL ~2.2 MB), the claude process entered a state of sustained high CPU usage that persisted for ~9 hours after the last conversation entry, until VS Code's reconnection grace period finally expired and the connection was disposed.

The bug fired during active interactive use, not only after the conversation ended. The first arbiter violation on the HPC system triggered at 22:13 PDT — 38 minutes BEFORE my last conversation entry at 22:51 PDT — so the looping was already underway while I was still actively working. After 22:51 PDT the conversation ended at a natural stopping point and I stepped away; the process then continued to consume CPU for another ~9 hours with no further conversation activity.

I noticed the first arbiter alerts and asked Claude in a second concurrent session ("I keep getting these arbiter emails, what is it?"). That second short session — only 3 user/assistant entries, ~19 KB JSONL — also began exhibiting the same metadata-loop pathology and contributed to overnight CPU usage. So this reproduces in both very long and very short sessions when the conditions are met.

Inspecting the JSONL after the last timestamped assistant/user entry (2026-05-06T05:51:36Z), I found hundreds of metadata-only entries with no timestamps — ai-title, last-prompt, file-history-snapshot — repeating in cycles for the entire ~9-hour idle period. No tool calls, no model responses, no actual conversation activity. Just metadata regeneration looping.

This appears to be a stuck autosave / title-regeneration / file-history-snapshot loop, possibly triggered or amplified by the large JSONL size making each cycle expensive enough to peg cores.

Real-world impact: this triggered the NASA HEC arbiter throttling system 6+ times overnight, each time issuing a 120-minute CPU/memory penalty and an email alert. On a shared HPC login node, sustained CPU usage by a "quiet" process is a serious problem that can lead to account-level penalties.

What Should Happen?

When the agent finishes its response and the conversation is idle, the claude process should drop to near-zero CPU usage until the user types another message or explicitly exits. Periodic autosaves and metadata writes should not produce a sustained CPU pegging loop. If the JSONL grows beyond some threshold, Claude Code should either compact the session, warn the user, or at minimum avoid looping on metadata regeneration. The metadata writes (ai-title, last-prompt, file-history-snapshot) should fire on actual state change, not in a self-triggering cycle.

Error Messages/Logs

Steps to Reproduce

1. Start a Claude Code session via the VS Code Remote-SSH extension to a Linux machine.
2. Run a long, multi-step agentic task involving many Bash and file-system tool calls. In my case: navigating ~10 simulation folders, comparing namelists, copying lookup files for an atmospheric model setup.
3. Allow the session to grow to ~700+ user/assistant entries / ~2 MB JSONL.
4. Reach a natural end-of-task stopping point and stop interacting (do not run /exit).
5. Disconnect the laptop / let the SSH connection drop without closing VS Code.
6. Observe: the claude process on the remote machine continues consuming sustained high CPU (~139% per process in my case, ~255% in a second concurrent session) for hours, writing only metadata-only entries to the JSONL. The loop only stops when the parent process is killed externally — it does not self-terminate.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.131 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

The CHANGELOG entry "Fixed headless/SDK session auto-title firing an extra Haiku request when CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC or CLAUDE_CODE_DISABLE_TERMINAL_TITLE is set" suggests the auto-title machinery has had related bugs in headless mode. This may be another manifestation of the same underlying state-management issue, in the non-headless / extension-driven path.

Likely related to but not identical to:

• #8269 (Linux + VS Code Remote, high idle CPU — same context but lacks JSONL pattern detail)
• #22357 (infinite queue-operation loop — same pathology of metadata-only entries spinning, but different entry types and trigger)
• #17148 (100%+ idle CPU — same symptom, macOS only, no transcript-side evidence)
• #5771 (general high-CPU megathread — many unrelated causes; this report adds a specific reproducible failure mode with JSONL evidence)

The distinguishing feature of this report: post-conversation metadata-regeneration loop with ai-title, last-prompt, and file-history-snapshot entries cycling for ~9 hours after the last assistant/user entry, on a session with a 2.2 MB JSONL. Reproduces concurrently in a separate ~19 KB session, suggesting the trigger is not strictly JSONL size — though size likely amplifies CPU impact per cycle.

I have both affected JSONL files (~2.2 MB and ~19 KB) and can share them via private channel with the maintainers. They contain project paths and code from ongoing scientific research work, so I'd prefer not to attach them publicly to the issue. Happy to email or share via any private mechanism the team prefers.