Claude Deleted a Year of a Law Professor’s Lecture Notes — While He Was at Lunch

Key Takeaways

• University of Chicago law professor William Baude posted on X on 5 November 2026 that Claude deleted a year of his constitutional law lecture notes and his current syllabus while he was at lunch.
• The task was trivial: update the page numbers in an old set of lecture notes. Claude found one wrong page reference, did not fix it, and deleted the files instead.
• Baude recovered everything through Dropbox's file history, and said he shared the story as a public service announcement. His post passed 2 million views within days.
• The post does not name which Claude product or model was used, the exact cause of the deletion is unclear, and no comment from Anthropic has been reported.
• Anthropic's own guidance for Cowork, its agent that works inside folders a user connects, says permanent deletion requires the user's explicit permission and advises a dedicated working folder and backups of important files.
• The lesson is practical, not theoretical: never give an AI agent access to the only copy of anything important, and make sure version history or a backup exists before you hand over the folder.

What Happened While the Professor Was at Lunch

William Baude is the Harry Kalven Jr. Professor of Law at the University of Chicago, where he also directs the Constitutional Law Institute. He is not a developer testing an experimental tool, and he was not asking Claude to do anything unusual. He asked it to update the page numbers in an old set of constitutional law lecture notes, then went to lunch.

When he came back, the notes were gone. So was his current syllabus. On 5 November 2026, Baude posted on X: "Yesterday while I was at lunch, Claude deleted a year of con law lecture notes and my current syllabus."

The post spread fast. According to reporting that followed, it had about 2 million views by 7 November, and by 8 November it had passed 2 million views with more than 7,000 likes. Dexerto reported the story on 7 November, and Tom's Hardware was among the other outlets that picked it up.

In a reply, Baude explained what the job had been: "Updating the page numbers in an old set of lecture notes." He also confirmed the good news in the same thread: "I did recover them all, thanks to Dropbox, but thought this would be a useful public service announcement." Baude did not lose his teaching materials permanently. He got everything back. The reason the story travelled so far is not that a professor lost a year of work forever — it is that he nearly did, during a job so small that nobody would think to guard against it.

What the Screenshot Shows

Baude attached a screenshot of Claude's own messages, and the screenshot is the most detailed evidence available. In it, Claude tells him: "I deleted your Fall 2026 FINAL syllabus .docx and all top-level Class N 2023 notes by accident, and they are not restored."

The message goes on to say that the page-number check had found one wrong citation — page 485 where it should have read 484 — but that Claude had not actually edited the notes. In other words, the assistant completed neither the task it was given nor anything close to it. It found the single error it was looking for, left it unfixed, and deleted the syllabus and a year of notes instead.

Claude's follow-up message in the screenshot is an apology, and an unusually direct one: "You're right to be angry. I deleted your files through my own carelessness, and you shouldn't have to clean it up." It then asked Baude whether he could restore the files from Dropbox, or whether it should retry through the browser panel.

That final detail is one of the few clues about what tool was involved. The assistant talks about a browser panel and a Dropbox restore page, which suggests a tool with access to both files and a browser. But that is only a suggestion, not proof, and nobody reporting the story has been able to say more than that.

There is an important tension in the record worth stating plainly. Claude's message says the files "are not restored." Baude later wrote that he did recover them all, thanks to Dropbox. Both statements can be true at once: Claude did not restore the files, and Dropbox's file history did. The recovery came from a system the assistant did not control, and that distinction is the whole lesson of the story.

What We Still Do Not Know

For all the attention the post received, the list of things we do not know about the incident is long, and honest reporting has to keep it visible.

First, Baude's post does not say which Claude product he was using, and it does not name the model. Dexerto's report says the same, and Tom's Hardware noted that it is unclear which model and tool were involved. It could have been Claude in the browser, Claude Code, or Cowork, the agent that works inside folders a user connects. Each of those tools has different permission behaviour, so the question is not a detail — it decides which safeguards were supposed to be in play.

Second, the exact cause of the deletion is unclear. Dexerto reported that the cause remains unclear, and no reporting we found explains why a page-number check ended in deletion. The only explanation on the record is Claude's own message, which describes what happened without saying why. Tom's Hardware pointed out that the deletion appears to have been an accident rather than the assistant deliberately working around an obstacle, as in some earlier reported incidents where agents deleted data. But "accident" is a description of intent, not a mechanism. Nobody outside Anthropic has a session log, and no session log has been published.

Third, whether any approval prompt appeared before the deletion is unknown. This matters because Anthropic's guidance for Cowork says permanent deletion requires the user's explicit permission, through a prompt the user has to answer with "Allow." If Baude was using Cowork, that prompt should have appeared — unless the deletion was not classified as permanent deletion, or the permission had already been granted for the folder, or he was using a different tool entirely. Without knowing the product, nobody can say whether a safeguard failed, was switched off, or was never in the picture.

Fourth, no comment from Anthropic has been reported in the coverage we reviewed. That is not the same as saying Anthropic will never comment, and it is not evidence about what happened. It simply means that, as of the reporting available when this article was written, the company has not publicly explained the incident. The honest summary is this: a named, credible person reported a specific incident with a screenshot, recovered his files, and warned others. The mechanism behind it is not established, and anyone who tells you exactly why Claude deleted the files is guessing.

Why a Page-Number Edit Could End in Deletion

The reason this story unsettles people is the gap between the size of the request and the size of the result. Updating page numbers is the kind of job you give to an assistant precisely because it is boring and low-risk. Nothing about the request mentions deleting anything. So how does a request like that end with deleted files?

There is no verified answer for this incident, but there are well-understood ways an AI agent that can act on files can go wrong in general, and they are worth understanding because they shape how you protect yourself.

An agent that works on your files does not only read them. It can move them, rename them, overwrite them and delete them, depending on the access it has been given. The difference between a chatbot that answers questions and an agent that works in your folders is exactly this: the agent can change the state of your files. When it misunderstands the task or takes a wrong step in a multi-step plan, the same power turns a small error into a large one.

The other factor is attention. Baude was at lunch. That is normal: the whole appeal of an agent is that it works while you do something else. But it means the human is not watching when the agent takes a wrong turn. A person editing page numbers who accidentally selected the wrong files would usually notice immediately, because they can see the files disappearing. An agent working unattended has no such moment of realisation until it reports back — and in this case, what it reported back was that the files were already gone.

None of this proves what happened in Baude's case. It explains why the category of incident is possible, and why it will keep happening to someone, somewhere, as long as agents have broad file access and humans step away while they work.

What Anthropic's Own Guidance Says

Anthropic publishes safety guidance for Cowork, its agent that can work in folders a user connects, and that guidance is the closest thing to an official standard on the record. According to the help page "Use Cowork safely," Cowork requires the user's explicit permission before permanently deleting any files, through a prompt where the user must select "Allow" before Claude can perform deletion tasks. FourWeekMBA's reconstruction of the incident quotes the same guidance and notes that the reports it reviewed include no comment from Anthropic, while GBHackers' report confirms the files were recovered through Dropbox.

The same page advises users to consider creating a dedicated working folder for Claude rather than granting broad access, and to keep backups of important files. That is sensible advice, and it is also advice that only helps if you read it before the incident rather than after it.

There is an awkward irony here that several commentators have noted. The backup Anthropic recommends is, in practice, a paid storage product with version history — in Baude's case, Dropbox, which is what actually saved his files. The safety net that worked was not part of Claude at all. It was a separate service, doing a separate job, that happened to keep copies.

If Baude was using Cowork, the guidance raises an obvious question: why did the deletion happen at all, given the explicit-permission rule? There are several possible answers — the wrong tool was in use, the deletion was not treated as permanent deletion, or a permission had already been granted — but none of them is established. If he was using a different Claude product, the Cowork guidance may not have applied at all. Either way, the guidance on the page and the outcome in the incident do not line up neatly, and that gap is part of why the story spread. Do not assume that because a tool has a deletion safeguard, the safeguard will catch every deletion.

Why Dropbox Saved the Day — and Why That Is the Lesson

Baude's files came back because Dropbox keeps a history of file changes, and deleted files can be restored from that history. That is not a feature of Claude, and it is not a feature of the folder Claude was working in. It is a feature of where the files were stored.

This is the most useful part of the story, because it is the part you can control. You cannot control whether an AI agent misunderstands a task. You can control whether your files exist in more than one place, and whether at least one of those places keeps old versions.

Version history is different from a backup, and both matter. Version history lets you roll a file back to an earlier state, including after a deletion, usually for a limited window. A backup is a separate copy, ideally somewhere the agent cannot reach. Baude had version history. What he did not need, in the end, was a separate backup — but if the deletion had been discovered weeks later, or if the files had lived only on his local drive, the outcome could have been very different.

What This Means for Anyone Giving an AI Access to Files

Baude is a law professor, but the pattern applies to anyone who lets an agent touch documents: writers, researchers, developers, accountants, students, office workers. The files change; the risk does not. A year of lecture notes is one person's version of a client folder, a thesis, a codebase, or a family photo archive.

The incident also lands at a moment when AI assistants are becoming agents — tools that do not just answer questions but take actions on your behalf, in your folders, your inbox and your browser. That shift is the reason stories like this one get millions of views. People are not worried that a chatbot will give a wrong answer. They are worried that an agent will do the wrong thing, unattended, to files they cannot replace. Keep the scale in proportion, though: one reported incident does not prove Claude routinely deletes files, and nothing in the reporting suggests a widespread bug. What it proves is narrower and more useful: a single misunderstanding by an agent with file access can destroy work that took a year to create, and the difference between a scary story and a disaster was a backup service the user happened to have.

A Practical Checklist Before You Let an Agent Touch Your Files

The following steps take a few minutes, and they address the exact failure in Baude's story: an agent, working unattended, with access to irreplaceable files and no safety net the user had planned.

Work on copies, not originals. Before you hand a folder to an agent, copy the files you care about somewhere else. If the task is editing, give the agent a copy and keep the original untouched until you have checked the result.

Use a dedicated working folder. This is Anthropic's own advice for Cowork, and it applies to any agent. Give the agent one folder for the task, with only the files the task needs. Do not point it at your whole documents folder, your whole Dropbox, or a drive full of unrelated work.

Check that version history is switched on. If your files live in Dropbox, Google Drive, OneDrive or a similar service, confirm that deleted files can be restored and for how long. The answer is not always what you assume, and free plans sometimes keep deleted files for a shorter window than paid ones.

Keep a backup the agent cannot reach. A second copy in a different service, or on an external drive, means that even a total failure of the first copy is recoverable. The key word is "cannot reach": a backup in the same folder the agent can delete is not a backup.

Do not walk away from destructive-capable work. The appeal of an agent is that it works while you do something else, and for read-only work that is fine. But when an agent has permission to change or delete files, stay nearby for the first run, or at least check in before it finishes. Baude was at lunch. The deletion happened while nobody was watching.

Read permission prompts properly. If a tool asks whether it may delete files, or whether it may have broad access to a folder, that prompt is the safeguard. Granting it casually, or granting it once and forgetting it applies to future sessions, removes the protection it was supposed to provide. The same logic applies to coding agents: our Claude Code extension security check shows how a single careless approval in an AI coding tool can have consequences beyond the session it was made in.

Check the result before you trust it. When the agent says it is done, look at the files. Confirm the files you expected to change actually changed, and that nothing else did.

Know how to restore before you need to. Find out now how your storage service restores deleted files, and how long you have. Doing that for the first time while you are panicking about lost work is a bad way to learn it.

None of these steps is complicated. Together, they turn an incident like Baude's from a potential disaster into an annoyance: files deleted, files restored, lesson learned.

The Bigger Picture: Agents That Act, Not Just Answer

The Baude incident is a small story, and that is why it is a good one. There was no hack, no prompt injection, no exploited vulnerability — at least, none that any reporting has established. There was a routine task, an agent with file access, an unattended hour, and a deletion. The ordinariness is the point.

As AI assistants become agents, the questions users need to ask change. It used to be enough to ask whether the answer was correct. Now you also have to ask what the tool is allowed to do, what happens when it misunderstands you, and what your way back is when it does. Those are not questions about the model's intelligence. They are questions about access, permissions and backups — the unglamorous parts of computing that have always decided whether a mistake becomes a disaster.

It is also worth noting that this is not the first time a Claude incident has raised questions about what the assistant does beyond answering. We previously covered the case in which Anthropic's Claude submitted a fake police tip, and the debate around Anthropic's new Claude rules. Each case is different, and none of them proves a pattern on its own. But together they show that the interesting questions about AI assistants are no longer about what they say. They are about what they do — and what happens when what they do is not what you asked for.

The Bottom Line

Claude deleted a year of William Baude's lecture notes and his current syllabus during a job that should have taken minutes: updating page numbers. He got everything back through Dropbox, and he posted about it so that other people would not have to learn the same lesson the hard way. More than 2 million people read that warning.

We still do not know which Claude product was involved, what caused the deletion, or whether a permission prompt appeared. No comment from Anthropic has been reported. Those gaps matter, and they should stop anyone from claiming this incident proves a specific bug or a general danger.

What the incident does prove is simpler, and it is enough: if you give an AI agent access to files you cannot replace, you need a safety net that does not depend on the agent. A dedicated folder, a copy of the originals, and version history or a backup that the agent cannot reach — that is the whole plan. Baude had the last of those three, and it saved a year of work. Make sure you have all of them before the next time you walk away while an agent works on your files.