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.

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?

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.

$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.