Allowlisting some Bash commands is often the same as allowlisting all (joinformal.com)

“…with Claude Code”

Same thing for allowing specific sudo-commands. Many tools (like vim or the tools mentioned in the article) would have the same problem when allowing them to be run with root privileges.

Allowing a "command" (executable, I believe) that isn't a read-only absolute path is a fool's errand. I will modify PATH and run my own implementation of it.

I know they’re just being through but the “go test” part is a bit “Pray, Mr Babbage”… Test code is just code. I know of no language where tests are sandboxed in any meaningful way.

everything is a container these days, and yet somehow collective-we don't manage to have AI agents run in a container layer on top of our current work, so we can later commit or rollback?

> I really thought `eval` would not be abused on non validated input

    - your colleague, or you 1 year before.

True, you can do almost anything if find is allowlisted.

find / -exec sh -c 'whatever u wanna do' \;

I'm sorry but the idea of giving an AI agent a non-restricted shell is insane. If you don't want it to perform certain commands those commands should not be in its environment at all.

I remember when I was starting out, someone on my team showed me, that in the case where we were allowed to run vi and root on a machine there was noting stopping one from just starting a child shell from within vi with root privileges.

Not entirely related to the content but man 'allowlisting' reads so badly. We should just out of ease of reading return to whitelisting.