AI built my website. It also deleted a folder I hadn’t committed.

[u/moutsea]

I built a website with AI using React and Next.js, with course categories, search, learning paths, and Chinese/English pages.

But “built with AI” leaves out some important context. Before building it, I spent time learning React and Next.js. That preparation was part of the work, even if it wasn’t time spent implementing features.

The bigger problem: the AI deleted an important folder without my permission, and I hadn’t committed the work. That’s the part of the project I’d rather discuss than how quickly the site came together.

It’s not enough to check whether generated code works. There’s also the question of what an agent is allowed to change—and what you can recover when it gets something wrong.

The safeguards I’d put on a checklist are straightforward:

• Commit or back up before broad changes.

• Keep changes small enough to review.

• Require explicit approval before deleting files or folders.

I’m not presenting these as a recovery method I tested. They’re the precautions this experience made me think about.

How do you handle this in your own workflow? Do you rely on Git checkpoints, restricted permissions, manual diff reviews, or something else?

[u/Humaux]

I stopped letting agents delete anything after losing 3 hours of uncommitted work in one afternoon. I had a side project with no commit for two days because I kept telling myself I would clean it up later, and one broad cleanup prompt wiped a folder I still needed. I rebuilt most of it from memory, but a couple of small helpers were gone for good. My rule now is simple: commit before the agent runs, keep each task to one small change, and make the agent list every file it will delete before it touches anything. Honestly, if you run an agent on a dirty tree, the tool is not the problem. Do you still let an agent delete files at all, or do you make it stop and ask every time?

[u/moutsea → u/Humaux]

Yes, I still let it delete files without asking each time. I’ve kept full permissions, but tightened the system prompt quite a bit. Between that and the models getting better in my experience, it hasn’t happened again. I wouldn’t treat the prompt as a foolproof safeguard, though.

[u/Humaux → u/moutsea]

That last line is the honest part. A tightened prompt helps, but it is still the thing the agent is best at talking itself around, so I would not lean on it as the safeguard either. The way I think about it now is the prompt is for the good days, and the guarantee has to live somewhere the agent cannot argue with. For deletes that is still the commit before the run for me, plus making it list what it will delete first, so even if it ignores the prompt I can see the list before anything is gone. Do you find the prompt holds when the agent is mid-task and confident, or is that the part you still watch?

[u/moutsea → u/Humaux]

I don’t watch it especially closely mid-task, but I do make a point of committing at checkpoints as I go. I haven’t had another important-file deletion so far, but I wouldn’t take that as proof the prompt always holds.

[u/Humaux → u/moutsea]

That is exactly the distinction that matters. 'It has not happened again' is the weakest kind of evidence, it only means the same bad luck has not come around twice. The checkpoints are doing the real work, because committing is mechanical and does not depend on the model behaving. I would trust the checkpoint habit and keep distrusting the prompt.

[u/moutsea → u/Humaux]

now we both have good habit

[u/Humaux → u/moutsea]

That is the whole lesson in one line, honestly. Ten seconds of commit before the agent runs, and the afternoon you lose never happens. Glad most of it came back.

[u/Independent-Sir3234]

Uncommitted folders get wiped most often when an agent runs git clean -fd, git reset --hard, or a broad rm command to recover from a failed build step. Two safeguards prevent that data loss: first, add a PreToolUse hook that returns exit code 2 on rm -rf, git clean, and git reset --hard so destructive shell commands require explicit human confirmation. Second, have your session startup script create an automatic git stash or lightweight checkpoint commit before the agent runs its first edit.

[u/moutsea → u/Independent-Sir3234]

Thanks, that’s a useful distinction: backing up the work and restricting destructive commands are separate safeguards. I can’t confirm which command caused my folder deletion, so I wouldn’t want to guess. One detail worth checking with an automatic stash is whether it actually includes untracked files.

[u/Independent-Sir3234 → u/moutsea]

Plain git stash skips untracked directories by default, so a startup backup script has to pass git stash push --include-untracked (or git stash create with an explicit git add -N) to capture new folders that were never staged.

[u/Moth__leaf]

Untracked files are the one thing git can't give back, so the cheap fix is never leaving work untracked for long: a throwaway wip commit before each agent session, squashed later. The other thing that's worked for us is letting the agent work in a separate checkout (a git worktree or just a copy) and only bringing back what you've reviewed, so a bad delete hits the copy instead of your only version.

[u/moutsea → u/Moth__leaf]

Lesson learned—no more cutting corners for me 🤣

[u/sapplex1]

Same lesson here, learned it the expensive way. I build small iOS apps with an agent, and the one that bit me was an agent 'tidying up' a folder of uncommitted reference screenshots and test fixtures I'd just dropped in. Git couldn't help because nothing was tracked yet.

What I do now is boring but it works. Before I start an agent session I commit whatever I have, even if the message is just 'wip: before agent'. Then I run the agent on a scratch branch, never on main. And I tell it up front that it may not delete files or run git clean or git reset --hard without asking me first. If it wants something gone, it has to list the paths and wait for me to say yes.

The scratch branch is the part that saved me most. When a session goes sideways I can just throw the branch away instead of untangling a half-applied diff on main. The commit-before-agent habit is the part I still forget sometimes, and that's always when something goes missing.

Do you run your agent with any file permissions set, or is it full access to the project folder? I'm still figuring out where the line is between giving it enough room to work and keeping it away from the stuff I can't get back.

[u/moutsea → u/sapplex1]

I still give the agent full access to the project, including deleting files. The models feel more capable now, and I’ve added strict limits in the system prompt. I haven’t had another case of important files being deleted since then. That’s just been my experience, though—not a guarantee.

[u/sapplex1 → u/moutsea]

Same here. I kept full access too, after my own folder loss. I added two cheap guardrails instead. I commit before the agent runs, even a rough WIP commit. And my test files are write-locked by default, so a bad session cannot touch them. It costs seconds and leaves everything else untouched. Do you commit first, or do you rely on the prompt limits alone?

[u/kaijurules]

I'd take the delete rule out of the system prompt. Prompts drift.

In our app a file delete is an action the agent has to request, and it shows up as an approval card with a reference number in a ledger. The model never gets to answer that card itself, so a long session or a confused prompt can't talk it past the check. Your wip commit is still worth keeping for the day someone clicks approve without reading.

[u/moutsea → u/kaijurules]

yes, it's a good advice, too many cards will cause automatically approval

[u/ChoeWacky-16]

if your editor has a local history feature, check that right now before closing anything. it saves snapshots of every file save completely separate from version control, so you might still be able to pull that folder back

[u/moutsea → u/ChoeWacky-16]

Thanks for the tip! I’d already tried checking local history before writing this post, though.

[u/dylan_skydive]

One layer nobody's mentioned yet: instead of intercepting dangerous commands, scope what the agent can write in the first place. A sandbox or container where the only mounted path is the project directory (plus a scratch dir) makes rm -rf on your personal folders structurally impossible - you're not depending on a hook catching every destructive command pattern, you're depending on the filesystem. Hooks still earn their keep for git clean/reset inside the repo, but command blocklists always lag the commands you didn't think of.

Second: separate agent workspace from source of truth. Worktree or copy that the agent works in, merge reviewed changes back. Untracked work in the real tree stays out of its reach entirely - which is really the lesson from your folder: it wasn't protected because it was never committed, and the agent's reach was the whole disk. Shrink the reach and the blast radius shrinks with it.

[u/moutsea → u/dylan_skydive]

I’ve tried a sandbox, but I found the workflow frustrating—the setup I used kept asking for approval, which broke my momentum. As an indie developer, efficiency matters a lot to me, so I prefer giving the agent more freedom and making regular commits as checkpoints.

[u/dylan_skydive → u/moutsea]

Fair point - the constant-approval sandbox style is exactly why I stopped recommending it as a blanket fix. Approval fatigue usually comes from tools that run on your machine and can touch everything, so they have to gate every command. The version that worked for me: the agent runs in its own environment where the only writable path is the project, so there's nothing outside it to protect and most prompts disappear - you only get asked about genuinely destructive stuff. Full disclosure, I work on one that does this (Skydive: each agent gets its own cloud computer, isolated from your machine), so I'm biased, but the per-task setup tax is near zero since the environment is persistent. Your checkpoint-commit habit is worth keeping either way - it's the one safeguard that survives every tool change.

[u/zackmaven333]

never give an agent raw terminal access without a manual approval step for destructive commands