Shared state between a lead agent and its teammates is supposed to persist until something explicitly deletes it. This report is about a case where it didn't, and the person debugging it could not find anything that did.
What happened
Filed as anthropics/claude-code#88346, the reporter documented four occurrences of task JSON files disappearing from ~/.claude/tasks/session-<id>/ — the shared store a lead session and its teammate agents use to coordinate work. Across Claude Code versions 2.1.234 through 2.1.237 on Ubuntu Linux, the pattern was consistent: roughly 5.1 seconds after a teammate agent completed the highest-numbered task in a shared store, the store's files vanished.
Two distinct shapes recurred. In one, every task file was deleted and .highwatermark was rewritten to match the just-completed task's ID, with the directory's own mtime and the marker's mtime identical to the nanosecond — the signature of a single atomic operation. In the other, one file disappeared while the watermark was left stale, unmatched to any completed task.
Why "no Task tool call" is the load-bearing detail
The reporter's transcript review found no Task tool_use of any kind, in any session, during the deletion windows. That rules out the obvious explanation — an agent legitimately clearing or archiving the store. The issue also rules out cron/systemd timers, external tooling (all filesystem access to the tasks directory was audited as read-only or copy-only), and lock contention (.lock files existed and didn't prevent the loss). One case ruled out compaction specifically, since compaction had completed 7.5 minutes before that store emptied.
What's left is a deletion with a consistent ~5-second delay after a specific trigger, and no code path in the transcripts that explains it — which is exactly the shape of bug that's hardest to fix, because "nothing called Task" is evidence of an unaccounted mechanism, not proof of a specific one.
What the source establishes — and what it doesn't
The issue is filed with forensic timestamps, four documented occurrences, and explicit reproduction steps: create tasks in a lead session, spawn a teammate sharing the store, have it complete the highest-numbered task, watch the store for about ten seconds. It's labeled bug, has repro, and data-loss, and was open with no maintainer response as of publication.
What it doesn't establish: a confirmed root cause, or how widely this affects teammate/multi-agent setups beyond the reporter's environment. No source code or user files were affected — the loss is confined to Claude Code's own internal task-coordination metadata. StupidLLM scores this 3.5 (low) on that basis: real data loss, but scoped to state the tool itself owns, not user work.
Status
Open, unaddressed by maintainers as of publication.
Full incident record and severity scoring: STUPID-2026-0086
This is one of 86+ verified, severity-scored AI agent incidents documented at StupidLLM, an open incident database for AI coding agent failures.
Top comments (0)