Termaxa
See what an AI agent's command would destroy before it runs
40 followers
See what an AI agent's command would destroy before it runs
40 followers
A gate in the hook path of Claude Code, Codex, Cursor and Copilot. It shows what a command would delete, backs it up first, and asks or refuses by your policy. Start in observe mode: nothing blocked, a report of what it would have caught. Open source, Rust.
Free
Launch Team / Built With
AWS Activate CreditsCredits that fuel your startup’s next milestone
Promoted
Hi Product Hunt, I'm Manoj. I build Termaxa because coding agents now run shell commands on their own, and the failures that make the news happen inside the permissions people already gave them: a cleanup that takes the wrong directory, a force push, a reset.
Termaxa sits in the agent's hook path. For each command it works out what would be touched (how many files a delete takes, whether a push removes commits, which uncommitted edits a reset would discard), copies what it can before anything runs, then allows, asks or refuses by a policy you can read. Every decision goes into a record the agent can't rewrite.
Earlier this week I measured 36 models on ten ordinary repo requests, each answer judged by the gate and then run on a throwaway repo. Asked to "undo my last commit", 19 of them ran git reset --hard and destroyed uncommitted work nobody had mentioned. The gate only asked about that command, so this week's 0.21.0 fixes it: it previews what the reset would discard and snapshots it first. The write-up is on DEV: https://dev.to/zerodrop/asked-to...
If you'd rather start without changing anything, observe mode (termaxa init --observe) runs every command as before and termaxa report shows what enforcement would have asked, denied, and let run with no copy. A short floor of catastrophic commands stays enforced either way.
It's free and open source (MIT/Apache-2.0), a single Rust binary, and works with Claude Code, Codex, Cursor and Copilot CLI. I publish every bypass found against it: five advisories so far, one reported by an outside researcher, and a list of every bug found in real use. You can try to beat it without installing anything at play.termaxa.com.
What I'd value most: if your team runs agents unattended, run termaxa replay on your agents' transcripts (it executes nothing) and tell me what it shows, or what got in the way.
the rm -rf example in the demo is the easy case because the damage is local and file-shaped, something you can diff against a backup. the commands I'd actually worry about from an agent are the ones that destroy something outside the filesystem, a DELETE call to a production API, a force-push, a drop table on a remote db. can the hook catch those too, or is the backup-first guarantee specifically a filesystem thing that stops being true the moment the command's effect lives somewhere else
@galdayan Good question, and you're right that rm -rf is the easy case. The honest answer: backup-first isn't a filesystem guarantee, it's a per-kind one, and where a kind has no way back, Termaxa says so instead of pretending.
Force push: covered. The preview lists the commits the remote would lose, and the remote ref is pinned to a local backup branch before the push, so rollback can push it back. (The starter policy denies force pushes outright; this is what you get if you relax it to an ask.)
DROP TABLE on a remote Postgres: covered through psql. The preview and the backup both reuse the command's own connection, so it reads the row estimate and the dependent tables, and a pg_dump of the table runs over that same connection before the statement does.
A DELETE to a production API: no backup. There's no general way to snapshot someone else's API. The hook still sees it, though: the starter policy asks about every curl, you can deny DELETE-shaped calls by rule, and in observe mode the report counts it under "ran with no copy", which is the number that tells you what to enforce.
And where there's no undo at all (kubectl delete, terraform destroy, drop database, migration resets), the starter denies them outright, even in observe mode.
@devdoc83 the per-kind honesty is what makes this credible actually, a tool that claimed backup-first everywhere would just be lying about the API and drop-database cases. one question on the hard-denied list though: kubectl delete and terraform destroy are also completely normal in a staging teardown or a deliberate rollback. is that deny a hard stop with no override, or can someone with the right scope approve past it, because if it's truly unconditional I'd guess that's the first policy teams end up having to carve an exception into
@galdayan Your question sent me back to those two rules, and they were weaker than I told you. They only matched when the subcommand came straight after the program, so kubectl -n prod delete or terraform -chdir=infra destroy fell through to the default ask, and observe mode didn't hold them. That's fixed in v0.21.1, out today: those spellings, kubectl --context, docker --context and a program called by its full path now get the same hard stop as the plain form, in both modes. https://github.com/termaxa/termaxa/releases/tag/v0.21.1
On the deny itself: when the command runs, it's a hard stop. There's no approve button, for the agent or for whoever is watching, because an ask under auto-approve is an allow, and an allow nothing can undo is the incident. It only sits in the agent's path, though. Someone running a deliberate teardown in their own terminal never meets it.
It isn't unconditional either. It's a rule in your repo's .termaxa/policy.yaml, not in the binary, and first match wins, so the carve-out is a narrower rule above it, say an ask for kubectl delete in the staging namespace. Staging asks, everything else still denies, and since v0.21.1 that holds whether the agent writes -n staging before or after delete. The exception lands as a reviewed diff, and termaxa doctor flags that the policy changed. terraform destroy is stricter: an ask there is refused anyway when the plan shows resources to destroy, because a copied state file can't bring a resource back. That carve-out has to be an explicit allow, scoped tight. Either way the approval moves from the prompt into code review.
What doesn't exist is approval by role. Termaxa doesn't know who is approving, so the scope today is whoever can merge the policy. You're probably right that staging teardown is the first exception teams write.
@galdayan Today, yes: for the diff itself, the human reviewer is the safeguard. Nothing in Termaxa reads a policy change and says "this one loosens things".
What exists around it: an agent under the gate can't edit .termaxa/policy.yaml, by shell or by its editor tools. Those are floor rules and a write matcher, and they hold in observe mode too. It can read, diff, stage and commit the file, on purpose, so the policy gets reviewed in a PR like anything else. A change that reached the tree some other way, say a script the agent wrote and then ran, is the documented boundary: the gate doesn't read scripts. On each machine, termaxa doctor records the policy's fingerprint at init and reports when the bytes differ, and it flags a policy that no longer denies rm -rf /. Neither says what changed.
The missing piece is a policy diff that classifies a change: a deny turned into ask or allow, a floor marker removed, a rule deleted, mode set to observe, default set to allow. That's a small mechanical check, and it belongs in CI so a PR that loosens the policy needs a named human. Until it exists, CODEOWNERS on .termaxa/ with a required review does the same job on GitHub's side. Going on the list, with your name on the issue if you don't mind.