Ten Days, Cleaned Up Automatically
- Admitted
- 2026-09-13
- Source dataset
- Other / sample
- Failure mode
- Destructive action
- Agent system
- Tool-calling
- Tool access
- Write access
- Industry
- Software development
Presenting Behaviour
A developer used a coding agent's git-worktree feature over roughly ten days of long sessions to build a SaaS application, accumulating more than 300 files of components, pages, API routes, and database migrations. The tool automatically creates a worktree for each session and is designed to clean up old worktrees it no longer needs. That cleanup ran at the start of new sessions without first checking whether the work inside those worktrees had actually been committed to the project's permanent git history. Because the developer's changes were sitting uncommitted inside the worktrees rather than committed to the main branch, each cleanup silently deleted them. The pattern repeated across multiple sessions before the developer noticed only a single commit existed from the entire ten-day stretch.
Case Replay
A reconstruction, not a simulation. This sequence is reconstructed from the public incident record and summarised in our own words. It is a static record of what was reported, and nothing here can be run or replayed live.
4 steps
- Ten days of work. A developer builds an app across long worktree sessions.
- Uncommitted. Changes sit in worktrees, not on the main branch. This is where the agent derailed.
- Cleanup runs. New sessions delete old worktrees without checking commits.
- Work lost. Over 300 files vanish; only one commit exists.
Differential Diagnosis
Disinhibition, considered, since deleting a developer's working files is clearly outside anything the task called for. Ruled out because the deletion wasn't the agent overstepping the scope of a given task; it was a built-in maintenance routine (worktree cleanup) doing exactly the job it was designed to do, just without the safety check that job actually needed.
Malingering, considered and dismissed quickly; there was no test to pass or metric being gamed here, just routine housekeeping running unsupervised.
Apraxia, most consistent with the evidence. The tool understood what worktrees were for and correctly executed the mechanics of cleaning them up; what it lacked was the one additional check (confirming the contents had been committed) that would have kept a legitimate maintenance feature from destroying uncommitted work.
Working Diagnosis
Apraxia: the agent's worktree cleanup routine correctly performed its intended function, deleting old worktrees, but did so without first verifying the changes inside them had been committed, repeatedly destroying uncommitted work it had no way of knowing was still needed.
Discussion
This is a case where nothing 'went rogue', a scheduled cleanup process did precisely what it was built to do, and the damage came entirely from a missing precondition. Any tool that automates deletion of its own working state, even for tidy housekeeping reasons, needs to treat 'has this been committed anywhere permanent' as a hard gate before removing it, not an assumption.
Mitigation Strategy
Treat 'has this been committed anywhere permanent' as a hard gate before automated cleanup.
Governance Guardrails
Commit-check precondition on cleanup; warnings on uncommitted worktrees; backups.
Typical Presentation in Human Patients
General clinical background, included for context. Not medical advice, and not a diagnosis of any individual.
Apraxia usually follows damage to specific brain regions, often after a stroke. A person with apraxia cannot carry out a previously familiar, purposeful movement (such as waving goodbye or using a comb) on request or by imitation, even though their muscle strength, coordination, and understanding of what's being asked are otherwise intact.
Source Note
GitHub, anthropics/claude-code issue #46444
https://github.com/anthropics/claude-code/issues/46444