Agent Teams: file-history-snapshot and queue-operation spam in JSONL transcripts

Resolved 💬 2 comments Opened Feb 24, 2026 by marcoabreu Closed Mar 25, 2026

Summary

Agent Teams session JSONL transcripts are heavily polluted with file-history-snapshot and queue-operation entries that fire in tight feedback loops (~40ms apart), consuming significant disk space and inflating token processing costs.

Reproduction

Using Agent Teams (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) with hooks configured (PreCompact, SessionStart, PreToolUse, TaskCompleted). The spam appears in virtually all sessions regardless of hook complexity.

The pattern in the JSONL is a rapid alternation of:

  1. file-history-snapshot (with identical tracked file backups each time)
  2. queue-operation enqueue (same message repeated)
  3. queue-operation dequeue (immediate)
  4. Repeat at ~40ms intervals

Example burst (15 cycles in 1.1 seconds):

{"type":"file-history-snapshot","messageId":"...","snapshot":{...},"isSnapshotUpdate":false}
{"type":"queue-operation","operation":"enqueue","timestamp":"2026-02-24T12:24:29.802Z","sessionId":"435982c3-...","content":"You're a team lead, you must not run tests yourself!"}
{"type":"queue-operation","operation":"dequeue","timestamp":"2026-02-24T12:24:29.848Z","sessionId":"435982c3-..."}
{"type":"file-history-snapshot","messageId":"...","snapshot":{...},"isSnapshotUpdate":false}
{"type":"queue-operation","operation":"enqueue","timestamp":"2026-02-24T12:24:29.885Z","sessionId":"435982c3-...","content":"You're a team lead, you must not run tests yourself!"}
{"type":"queue-operation","operation":"dequeue","timestamp":"2026-02-24T12:24:29.928Z","sessionId":"435982c3-..."}
// ... repeats indefinitely

Measured Impact (182 sessions analyzed)

| Metric | Value |
|--------|-------|
| Affected sessions | 180 / 182 (99%) |
| Total spam lines | 42,422 |
| Total lines in affected files | 143,708 |
| Spam as % of total lines | 29% |
| Bytes wasted on spam | 44 MB |
| Combined affected file size | 383 MB |
| Worst session | 91% spam (8,567 / 9,387 lines) |
| Sessions >50% spam | 8 |

Worst affected sessions

| Spam % | Spam / Total Lines | File Size |
|--------|--------------------|-----------|
| 91% | 8,567 / 9,387 | 19 MB |
| 89% | 9,943 / 11,137 | 5.4 MB |
| 84% | 5,941 / 7,056 | 5.2 MB |
| 78% | 4,686 / 5,978 | 11 MB |
| 65% | 1,254 / 1,916 | 4.6 MB |

Root Cause Hypothesis

file-history-snapshot events and queue-operation entries appear to trigger each other in a feedback loop. The snapshot/enqueue/dequeue counts are nearly 1:1 (e.g., 3,316 snapshots : 3,312 queue messages in one session), suggesting each snapshot triggers a queue operation which triggers another snapshot.

The snapshots contain identical data each cycle (same trackedFileBackups with unchanged versions and timestamps), indicating no actual state change warranting a new snapshot.

Expected Behavior

  • file-history-snapshot should only fire when tracked file state actually changes
  • Queue operations should not trigger new snapshots
  • Identical consecutive snapshots should be deduplicated or suppressed

Environment

  • Claude Code with Agent Teams enabled
  • macOS (Darwin 24.5.0)
  • Hooks: PreCompact, SessionStart[compact], PreToolUse[Bash], TaskCompleted
  • Version: 2.1.52
  • Feedback ID: 82b3d885-c0b9-460c-a877-dcf881760e27

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗