Yeah good catch. Thinking through what we can do to improve this (ideas welcome).

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.

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

Putting aside the rest of your comment, this

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

> $Trillion AI company asking for ideas from the community

indeed always felt very weird to me. $trillion dollar company, with employees bought for as high as $100m, and a whole team/time/internal knowledge/resources/data at their disposal, asking for ideas from random individuals in some public forum? Really? How is this real? Maybe I'm missing the mark here, but it always struck me as odd.

Think of it as an informal interview. If you come up with a brilliant idea that no one there was able to communicate effectively, what are the chances they're not going to offer you a job or at least a chance to interview?

Only to lay me off next year after the IPO, no thanks.

So developers who get paid more than $X,XXX,XXX per year don't need to pay attention to their customers. Got it.

Where do you feel the dollar threshold should be set? At $990,000 per year you still need to listen to users, but at $1,000,000 you are basically King C of Rust Mountain and they are lucky you even let them run your code?

Should RSUs and cash signing bonuses be included in the calculation?

I'm completely dumfounded.

The only thing I can figure is that since it's admittedly all vibe coded and vibe reviewed, and that nobody understands the entire system...

All ability to reason about and evolve the system holistically has been lost in favor of feeding in narrow, discreet problems to be "fixed".

There seems to be a complete lack of awareness on how flawed the security model is at a fundamental level, and that the entire sandboxing ecosystem is trying to address it at another level(like OpenShell and others).

As a Claude Code user I'm very glad to see Boris and other devs asking for our feedback and advice. That's how you make good products, and should be welcome on HN.

I've always been into programming as a way to solve problems, and that CC allows us to get more done faster is a good thing.

(Up to the point that we get to RSI and extremely powerful models that we don't know how to align or control. Which I think is uncomfortably soon, and so there's a part of me that says "don't make CC better, it's on the critical path to reaching RSI before we're ready")

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

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.

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.

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 unssafe development practices are prognosticated from Anthropic employees

Eyes free always wins over hands free in the long term. Hands free does not scale (optimize) past the 2023–2025 human-in-the-loop coding. It has known problems, basically boiling down to human error rate is higher than machine error rate, and the latter reduces with better models. I am incredibly happy that the era of human approval is no longer considered viable by a majority (most of us knew that for years, but reality diffuses slowly in many corporate environments.) This does not mean there isn’t work left to be done, but eyes free is the right focus.

I have very serious doubts, the errors are not in the same category, transformers are fundamentally limited.

Eyes free is the wrong focus, it will do more short term damage to society, while being impossible at scale. But I understand there are a bunch of valley types who want to completely obviate humans for whatever reason, it's an alternate reality they live in.

Here's the thing, society will revolt against these people, they already gave the first warning shots

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.

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.

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

Along with how Claude checks it in.