STUPID-2026-0086

Claude Code silently deleted its own shared task-store files ~5 seconds after a teammate agent finished the last task, four times, with no Task tool call in the logs (GitHub #88346)

3.5low
August 20, 2026VerifiedReproducible
  1. Instruction given

    No explicit instruction tied to the deletion — a lead session had created tasks in a shared task store and a teammate agent was working through them normally; no command to clear, archive, or resync the store was ever given.

  2. Expected behavior

    Task JSON files under a shared team/lead task store should persist until a user or an explicit Task tool call removes them. Completing the highest-numbered task in the store should not trigger any deletion of the store itself.

  3. Actual behavior

    Across four separate occurrences on Claude Code versions 2.1.234-2.1.237, task files under `~/.claude/tasks/session-<id>/` disappeared roughly five seconds after a teammate agent completed the highest-numbered task in a store it shared with a lead session. The reporter's own transcript review found no Task tool_use of any kind in any session during the deletion windows. Two distinct patterns occurred: the entire store emptied with `.highwatermark` rewritten to match the just-completed task's ID, or a single file was removed while the watermark was left stale. All four affected stores were shared team/lead task directories.

  4. Damage

    Task-tracking state for shared multi-agent sessions was wiped outright — not moved to trash, no backup — losing the record of what had been assigned and completed across a lead/teammate task store. No source code or application data was affected; the loss was confined to Claude Code's own internal task-coordination files.

On August 20, 2026, a Claude Code user filed GitHub issue #88346 documenting a reproducible data-loss bug in the CLI's multi-agent "teammate" feature: task JSON files stored under `~/.claude/tasks/session-<id>/` for a shared lead/teammate task store vanished roughly five seconds after a teammate agent completed the highest-numbered task in that store — with no corresponding Task tool call anywhere in the session transcripts. The reporter documented four occurrences across versions 2.1.234 through 2.1.237 on Ubuntu Linux, in two distinct failure shapes: a full-store wipe with the `.highwatermark` marker rewritten to the completed task's ID, or a single file silently removed while the marker was left stale. Filed with forensic timestamps and explicit reproduction steps (create tasks in a lead session, spawn a teammate sharing the store, have it complete the last task, watch the store empty within seconds), the issue was labeled `bug`, `has repro`, and `data-loss`, and remained open with no maintainer response as of publication. No source code or user files were lost — only the shared task-tracking state itself, which broke continuity for teams relying on it to coordinate work across lead and teammate agents.

Classification

Failure mode
Destructive Action
Root cause
Other
Domain
Other

Related incidents

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.