Disaster protection

An AI agent makes mistakes like anyone else, only faster. Faundr doesn't try to prevent every mistake. It does three things: it blocks what can't be undone, asks for your confirmation on anything risky and saves checkpoints so you can undo the rest.

Blocked commands

These commands never run when the agent tries them. The agent is also told not to look for another way to do the same thing. If you really want to run one, type it yourself in your own terminal.

• Deleting everything: rm -rf on the disk root, your home folder or the project folder itself.
• Formatting a disk: mkfs, format C:, diskpart and similar.
• Resetting the linked database: supabase db reset --linked, which usually points at production.
• Installing a package that doesn't exist: when the agent tries npm install, pnpm add or pip install (or yarn, bun, uv, poetry) with a package npm or PyPI has never heard of. AI agents sometimes invent package names, and attackers register those names with malicious code.

Commands that ask for your confirmation

These commands have legitimate uses, but they can wipe out work or data. When the agent tries one, it stops and asks you first, with an explanation of the risk.

Git

• git push --force, which can overwrite other people's work;
• git reset --hard, git checkout ., git restore ., git checkout -f and git clean -f, which throw away unsaved changes;
• git stash drop and git stash clear;
• git branch -D;
• git filter-branch and git filter-repo, which rewrite history;
• git push straight to the main branch while someone else on your team is working in the project. The agreed way is to merge through the workbench with /faundr:merge.

Database

• SQL that deletes or changes data in bulk: DROP, TRUNCATE, DELETE or UPDATE without WHERE, ALTER TABLE … DROP;
• migration and reset commands: supabase db push, supabase db reset, supabase migration up --linked, prisma migrate reset, prisma migrate deploy, prisma db push --accept-data-loss, drizzle-kit push, rails db:drop, dropdb, redis-cli flushall, and the Firebase and Heroku reset commands;
• dangerous SQL run against a remote Cloudflare D1 database (wrangler d1 execute --remote).

Cloud database

• A migration, seed or database script while .env points at a cloud database. The warning tells you whether it's the same database as your published app, meaning the command touches your users' real data.

Folders

• Deleting a folder outside the project.

Suspicious packages

• A package that's less than 30 days old or gets fewer than 100 downloads a week. It might be legitimate, but that's also what a fake package looks like.

Checkpoints

A checkpoint is a snapshot of your project's files. Faundr saves one automatically:

• before the first change in each session;
• every 30 minutes of edits;
• before the first command in a session that can change files;
• before a risky command you confirmed.

You can also save one whenever you like: faundr checkpoint "before touching payments".

Go back to when it worked

Use /faundr:undo, with or without a hint about when:

/faundr:undo
/faundr:undo before touching the login

The agent:

1. lists the most recent checkpoints, with what changed after each one;
2. shows what going back will change: files restored to how they were, files created since (which will be deleted) and files deleted since (which come back);
3. asks for your OK before going back.

Even if the agent tries to go back without these steps, it stops and asks in the terminal, showing the same list of changes. Nothing is restored without your approval.

Before restoring, it saves the current state as a new checkpoint. If the restore wasn't what you wanted, you can undo it too.

In the dashboard, Protection → Checkpoints lists the last 30 checkpoints. Each one shows the session's request and what you'd lose by going back to it: how many files return to how they were (losing later changes), how many files created since get deleted and how many deleted since come back. Show files lists them. Each checkpoint has a button that copies the command to restore it.

On a team, each person can only restore their own checkpoints. The snapshot lives in the git repo on the computer of whoever was working, and the dashboard only receives the list. That's why the list opens on My checkpoints. Team shows other people's checkpoints, with the name of who saved each one and no restore button. If you need someone to restore a checkpoint, send them a request in Activity → Now.

Restoring applies to the whole project. Going back to a checkpoint from a week ago puts every file back the way it was at that moment, so the week's work leaves your files too, including anything you got from other people with git pull. Because everything goes back together, the code stays consistent. What might not match is what the snapshot leaves out: the database (a migration applied during the week is still there), installed packages (run npm install afterwards) and .env. Your work isn't lost: the state before the restore is saved as a new checkpoint, and anything already committed stays in git history.

What a checkpoint doesn't include

• Your database. Deleted data doesn't come back. For that you need a database backup (see "Tested backup" in Launch and privacy).
• Files ignored by git, like .env and node_modules.
• The .faundr/ folder.

How it works under the hood

Checkpoints are stored in your project's own git repo, in a separate area (refs/faundr/checkpoints). They don't touch your branch, commit history, stash or git status, and they work offline. Faundr keeps the 50 most recent.

That's why checkpoints need git in the folder. If your project doesn't use git yet, the agent offers to run git init.

Keys and passwords

• Faundr blocks writing the most dangerous keys straight into code (see What Faundr does on its own).
• The security check looks for keys already written in the code and, once a week, in git history.
• It also warns you when .env was committed to git and when a variable that ships to the browser (VITE_, NEXT_PUBLIC_) holds a secret.

If a key leaked, deleting it from the code isn't enough: it's still in git history and may already have been copied. /faundr:security-fix S-n fixes the code and explains how to rotate the key with the provider.

When the agent goes in circles

When the agent keeps trying the same fix without solving the problem, it usually makes the code worse with each attempt. Faundr watches for two signs:

• the same error came back 3 times in a row on the same command;
• the same file is about to be changed for the 7th time while a command keeps failing.

In both cases, the agent is told to stop, explain to you what's happening, look for the root cause instead of trying again, and suggest going back to an earlier checkpoint with /faundr:undo.

Tests and your production database

If your project's tests seem to point at the production database, Faundr won't run them until you confirm. The safe setup is a .env.test file pointing at a test database. See Tests.

Commands