⚠️How do I stop TRAE from using ssh?!🚨

I actually lived through one of those legendary horror stories you read about in the news!

TRAE used ssh to connect to my server and restart it without my consent — and it didn’t even need my consent?!
TRAE used ssh to connect to my server and restart it without my consent — and it didn’t even need my consent?!
TRAE used ssh to connect to my server and restart it without my consent — and it didn’t even need my consent?!

TRAE’s sandbox actually allows running ssh commands?!

ssh -i /Users/rhett/.ssh/id_rsa root@◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ 'cd /www/wwwroot/◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎/◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ && pm2 restart ecosystem.config.cjs'

My automation scripts can bump version numbers, commit to git, and upload to the server, but I hadn’t written a one-click restart yet. The damn thing inferred the restart method from my scripts and the package.json config.

It actually committed to git, ssh’d into the server, overwrote the files, and restarted it.

Call it smart — it didn’t fix the actual bug correctly at all!

Call it dumb — the half-baked thing had the nerve to infer the production server’s restart method and just went ahead and did it!

Earlier I saw online that someone accidentally wiped an entire drive’s worth of files with AntiGravity, and that seemed absurd too.

So damn it, unless it’s structurally prevented (i.e. a precise whitelist/blacklist permission control mechanism), something will definitely go wrong. Relying on prompts or the model’s capabilities is basically letting it guess — only taking away the tools of the crime can truly stop it from overstepping its authority.

I have a local dev environment and an external production environment; normally I test locally and then run a script to publish. The usual flow is build locally, then test, and only push to the external network once the tests pass.

This incident happened to be about an nginx config issue in the external production environment, and I probably asked a bit too casually. I said there was a bug in the external production server, pasted the 404 error log, and asked how to fix it — and TRAE just wrote the code and started operating on the external network.

But it wasn’t smart enough to diagnose the problem, so it fixed it as a code problem (which was completely wrong), and since it was running in sandbox mode it could publish straight to the external network without my approval. Then, because the production server started without errors, it reported back to me that everything was fixed! 🤯 Shocking.

So Lobster is dangerous, and agents like TRAE are dangerous too. If it doesn’t ask for your approval every single time, it’s not fucking safe — you can never be sure when it’ll screw you over, especially since it all runs on your own computer.

First, let’s salvage the git history:

git checkout main
git reset --hard 8b9080d0f34f3f5db0c2b586111ca2a045153092

Then commit again.

I searched for ages and couldn’t find a blacklist feature — the sandbox allows ssh by default, and there’s only a whitelist.

Logically, if it’s a whitelist, then anything I haven’t whitelisted shouldn’t be allowed to run, right?

I’d approved npm, cat and the like so many times that I set them to run in the sandbox, so I didn’t have to manually approve them every time.

But your sandbox freely uses the sensitive keys under my ~/.ssh/ — so what’s the point of the sandbox?

To prevent this kind of overreach from happening again, I had no choice but to switch everything to manual approval.