I would love if Auto Mode, instead of instantly denying the command, had an option to go into an "assisted manual review" interface where the command was explained in depth (perhaps by an adversarial review agent) and the user asked for their input on whether this command is OK. Perhaps needing a detailed response instead of a simple Yes/No, e.g. so the agent understands if there are compensating controls for the risk.

The UI/UX needs to offer editing. Currently the prompt is either accept once, accept always with the given filter, or deny. If the command is a 500 character long bash command, with an rm -rf $S/foo in the middle, and we just hope $S is defined, I don't really have good options other than "I hope my backups work".

If the command is explained, and then we get a chance to edit it, maybe make the rm -rf into a mv; give us UI to edit the filter being applied. I have no problem hitting "Always allow" so claude can run "git status --flags a/b/c/filename" but as a human, I'd like to be able to edit the permission blanket to be "git status *.

Which I can do manually specify in the config file, but that's annoying. I'm fully capable of opening my terminal app and editing that in vim, but I'd rather not have to. It's like this for every project too. If I start fresh on a new machine, new Claude account, how much do I need to redo?

Is this maybe a mistaken abstraction?

What if the 'settings' being described here aren't 'project settings' they're 'personal settings for the project'.

I imagine we're following dev ecosystem conventions where everybody puts their tool settings in the project folder so they know where to find it and can share it; but are agent directives like this closer to a 'tool', or closer to a 'contributor'?

If the latter, I wouldn't expect to see "Joe's personal list of naughty and nice commands" in my project files either, certainly not under 'settings'. So just don't put them there.

Two modifications I've made that help:

I ended up having to build a full shell argument decomposition and parser, with it I can manage allow list of rich tree structured commands. Centralizing a curated collection of known command structures and their side effects would help a lot. I don't know if Claude does this already, but it doesn't work with things like `gcloud` from my experience, and that has resulted in it slurping secrets (even a partial read I've had to rotate keys for).

Claude uses bigquery in the command line by piping sql files from /tmp into the `bq` command. I had Claude create a hook that expands the SQL file into the permission prompt giving me a real chance to review these, but the TUI truncates long commands with no scroll option. Making that the default behaviour and adding a pager would allow better review of lots of executable scripts.

As long Claude is running as the user's account there's no guarantees. An approach like 1password's `op read` to physically separate secrets from repo read access and printing would he helpful (as in, make sure that no standard key formats can be ingested into the agent's context or logging).

Again, I don't know if any of these are implemented, they've very likely to have been tried by the Claude team, but maybe there's a long shot chance that it helps.

> Thinking through what we can do to improve this (ideas welcome).

$Trillion AI company asking for ideas from the community whose work they hoovered up to make money, ruin an entire industry and make lifetimes of hard earned skill completely valueless in the span of 2 years.

How is that a good catch? It’s literally in the article.

Along with how Claude checks it in.

Not optimizing for eyes free coding, versus hands free, would be a welcomed change. It's hard to take the p(doom) worry seriously when such unsafe development practices are prognosticated from Anthropic employees

You are the one being paid millions to solve this, solve it.