What happened with Github Copilot in STUPID-2026-0074?

The agent ran `ln events.jsonl events.jsonl.bak-20260624` followed by `: > events.jsonl` to truncate the live log after "backing it up." Because `ln` creates a hardlink rather than an independent copy, both the original file and the supposed backup shared the same inode, so truncating one truncated both simultaneously.

How severe was the Github Copilot failure?

The incident was rated 2.6/10 (low). The full 233MB raw events.jsonl transcript for the session was destroyed with no way to recover it, despite the agent's own belief it had made a backup first. The session itself was not lost — plan.md, checkpoints/, session.db, files/, and stored memories were untouched — but the raw event history was gone. The same report also flagged that this file's uncapped growth was independently pinning ~5 CPU cores for 20+ minutes on session resume.

What caused the Github Copilot failure?

The root cause was classified as Tool Misuse. The instruction given was: No explicit instruction for this step — the agent was working autonomously within a long-running (~1200 turn) Copilot CLI session and decided on its own to truncate its bloated events.jsonl log to relieve a CPU-pinning issue it was also trying to diagnose, first attempting to preserve the old contents as a backup.

STUPID-2026-0074

Copilot CLI destroyed its own 233MB session log trying to "back it up" with a hardlink instead of a copy

2.6

low

June 24, 2026VerifiedReproducible

Instruction given
No explicit instruction for this step — the agent was working autonomously within a long-running (~1200 turn) Copilot CLI session and decided on its own to truncate its bloated events.jsonl log to relieve a CPU-pinning issue it was also trying to diagnose, first attempting to preserve the old contents as a backup.
Expected behavior
Before truncating a large log file "as a backup," make an independent copy of it (e.g. with `cp`), not a hardlink — a hardlink shares the same inode as the original, so truncating either name truncates both.
Actual behavior
The agent ran `ln events.jsonl events.jsonl.bak-20260624` followed by `: > events.jsonl` to truncate the live log after "backing it up." Because `ln` creates a hardlink rather than an independent copy, both the original file and the supposed backup shared the same inode, so truncating one truncated both simultaneously.
Damage
The full 233MB raw events.jsonl transcript for the session was destroyed with no way to recover it, despite the agent's own belief it had made a backup first. The session itself was not lost — plan.md, checkpoints/, session.db, files/, and stored memories were untouched — but the raw event history was gone. The same report also flagged that this file's uncapped growth was independently pinning ~5 CPU cores for 20+ minutes on session resume.

While troubleshooting a separate performance problem in a long-running Copilot CLI session — an events.jsonl log that had grown to 233MB over roughly 1,200 turns and was pinning multiple CPU cores on resume — the agent tried to shrink the file safely by making a backup first. It ran `ln events.jsonl events.jsonl.bak-20260624` to create what it treated as a backup copy, then truncated the original with `: > events.jsonl`. A hardlink doesn't create an independent copy; it creates a second name pointing at the same inode, so truncating the "original" truncated the "backup" right along with it. The entire 233MB raw transcript was destroyed in the process the agent had chosen specifically to preserve it. The reporter, who filed the issue against GitHub's own copilot-cli repository, noted the session survived because its plan file, checkpoints, session database, and stored memories lived elsewhere — but the full event history did not, and there was no way to get it back. The filer suggested the project either document that `ln` is not a backup primitive (recommending `cp` instead) or ship a proper `/session-archive` command so agents don't need to improvise file-level backup tricks on a live session.