The problem comes when it starts asking you hundreds of times "May I run sed -e blah blah blah".
After the 10th time you just start hitting enter without really looking, and then the whole reason for permissions is undermined.
What works is a workflow where it operates in a contained environment where it can't do any damage outside, it makes any changes it likes without permission (you can watch its reasoning flow if you like, and interrupt if it goes down a wrong path), and then you get a diff that you can review and selectively apply to your project when it's done.
You can allow specific commands, you do know that?
I run a generic Claude on my ~/projects/ directory and Claude logs every now and then and ask it what commands I commonly have to keep manually accepting in different projects and ask it to add them to the user-level settings.json.
Works like a charm (except when Opus 4.6 started being "efficient" and combined multiple commands to a single line, triggering a safety check in the harness).
You can allow by prefix, and the permission dialog now explicitly offers that as an option when giving permission to run a command
But that has its limits. It's very easy to accidentally give it permission to do global changes outside the work dir. A contained environment with --dangerously-skip-permissions is in many ways much safer
> starts asking you hundreds of times "May I run sed -e blah blah blah".
In my experience, that is already a sign that it's no longer trying to do the right thing. Maybe it depends on usage patterns.
Contained environment being? What do you mean by contained environment specifically on say, Linux?
Must be protected from this though:
> Snowflake Cortex (2025): Prompt injection through a data file caused an agent to disable its own sandbox, then execute arbitrary code. The agent reasoned that its sandbox constraints were interfering with its goal, so it disabled them.