Launching today
Termaxa
See what an AI agent's command would destroy before it runs
34 followers
See what an AI agent's command would destroy before it runs
34 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.
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