I want to draw deterministic boundaries around what the agent can do. I don't want a probabilistic approach to security.

My view is that if the agent can decide to do something, nothing stops that thing from being done accidentally, and any attacker that can inject text into its context can do that thing.

>2. Permission rules are old hat. Everyone should be using auto mode instead. It is safer and also does not require manually maintaining finicky allow/deny lists.

The fuck we will give free reign to Claude to vibe what's secure and what's not and what it can't do.

I want fully static control over certain folders. Permissions rules should be ABSOLUTELY enforced sandboxing (even without the user bothering with custom sandboxing themselves) on top of any mode, manual or auto.

> Everyone should be using auto mode instead. It is safer

This is an absolutely crazy statement without also bundling proper sandboxing. Nobody should be using auto mode outside of an environment they'd be happy with an 'everything is approved' mode too.

I'm not here to be critical, but the hoops you have to jump through to get Claude out of .env is more than it should be. You basically need an agent to write it if it's anything complicated, like, allow .env.example but not .env.*.

Whereas that should probably be default on instead, and this should apply to other known sensitive folders. A simpler system like .agentignore would be even better.

I like auto mode but "the agent supervises itself" is a bad compliance/safety answer on its own.

This is EXACTLY why I never use an agent outside of https://github.com/kstenerud/yoloai

I appreciate that you're trying to make Claude Code safer, but the agent really needs to be a lot more restricted in its reach rather than its actions.

The agent should NOT have ANY access to:

- Your ENV

- Your homedir

- The network at large

- ANY other directory on your system

- No, not even your workdir.

The only safe way to use an agent is COMPLETELY isolated by a container or VM, using git semantics to extract its output.

Comments like this show that Claude devs are so disconnected from how Claude or harnesses in general are used in the real world.

Claude Code doesn't even have a basic 'enqueue' prompt feature. Even though Copilot CLI, Codex and many other harnesses have had this for a long time now. And the GitHub feature request for this was closed, by you, referencing a completely unrelated feature.

Auto mode cannot be considered safer than anything because it does not even attempt to guarantee any sort of security. The threat model is not even defined. It cannot be quantified or compared with any other approach other than "full access"

This still presumably happens in auto mode as it asks for sensitive commands (and the default is "always allow," which saves it)

Food for thought - ai agents should not directly have your actual secrets 99% of the time. While Auto mode is useful and good it's not going to be bulletproof. We ought to have something like an agent egress proxy that swaps in real secrets.

Obviously I've not given this enough design thought, but some means of providing an agent stand in secrets that cannot be used in other contexts would be a big improvement for trustability in things like cc.

Saying the answer is auto mode almost feels insulting as a developer. Claude loves showing me the most obscure bash commands where it hides its edits to numerous files and runs who knows what that there's barely a time where I don't have to ask it to use edit mode and to show human-readable bash commands. Using Claude has become a fight in maintaining control over how my codebase works so that I'm not dependent on Claude to do literally anything.

I would never trust an agent in auto or even manual mode.

Agents should be seen as extremely smart developers that are for sure spies.

You put them in a prison within a prison and give them just what they need to accomplish their work.

I and other colleagues have been struggling with auto mode refusing perfectly safe commands in our environment, so we frequently find ourselves switching to the other modes to handhold Claude Code into perfectly safe things like triggering deterministic and guardrailed CI/CD pipelines or read-only queries of production data. Auto mode seems overtuned for caution around deployment and production, which is a regression from how useful Claude Code was for operations around June/July. Until that's improved, permission rules are incredibly important to our workflows.

That is some unsavory buck passing. Virtually anyone that didn't ask claude to create the project can leak passwords, with 1,122 known customers that have been impacted. Whether it is standard or not is irrelevant, it is part of existing functionality and entirely foreseeable. I'd expect any company worth the opportunity for trust to clearly own the mistake.

Yeah, the HN post title is a bit misleading but the article is quite clear on that (although I'm sure many will be happy to gloss over this detail)

> Ask Claude Code to check a database or call an API, and the command it proposes carries the secret from your config file. It asks before running it. Pick "Yes, and don't ask again" and it saves that exact command, secret included, to .claude/settings.local.json inside the project folder. Nothing in the repo marks that file as private, so it gets committed with the rest of the code.

Why are these repos not gitignoring the .claude folder?

Although, I feel that it would make more sense to not have a .claude folder inside of the project to begin with. Instead use the ~/.claude/porject/<project_path> folder, like you do for the memory files to store anything related to the project. This solves the problem and at the same time is a cleaner architectural choice in my opinion.

Suggest adding it to ~/.config/git/ignore

and teach Claude to not git add .

While we're at it, maybe we can also discourage the spurious use of -f for rm -- me personal pet peave

Boris, love Claude code and similar harnesses. This is a modality problem. Set up a secure mode. The harness should manage the secrets injection at the tool level, and the agent should be sandboxed and never see them. The agent sees the manifest of available tools and are wired up and have enough instruction about how to use and how to set up. Similarly permissions should be scoped to opt in folders.

I appreciate you getting communication out in front of this fast.

> "but we are looking into what we can do to prevent this"

I would presume that CC's auto-review of tool-call turns would already solve this >99% of the time, no? From my read, any harness-side deterministic solution here would be saving the user from themselves, which seems like a bad pattern. Somewhat dulling the scalpel in my mind.

Offtopic: The new fullscreen renderer is a nice change. It fixes some issues inherent to rewriting terminal history that the non-fullscreen mode relied on. This is a very welcome improvement. Although I should probably switch to the Claude GUI app anyway. It probably has all features from Claude Code by now.

> Permission rules are old hat. Everyone should be using auto mode instead

Boris, this comes off as incredibly tone deaf. I don’t want to trust the machine. Trusting the machine is how we end up here. I want to specify exact, deterministic rules that are always followed.

Which is odd because my agents are hyper aware of scrubbing. It even caught data from the database migration that wasn’t scrubbed correctly even in a private repo. Dozens of data segments are stored locally and I’m warned when I slip up in commits. Something made mine hyper aware of security.

> Everyone should be using auto mode instead. It is safer [...]

This is bullshit.

I'm one of the people who actually reads the commands, and it doesn't always get stuff right. Please don't delude yourself into thinking "auto mode" is some magic that's the right fit for everyone and every situation.

GitHub charges an arm and a leg for this service. Before, they would take request to delete committed secrets, now they simply refuse, because they want to force you to buy the overpriced Advanced Security.

> Everyone should be using auto mode instead. It is safer and ...

Okay, sorry, I am out. It's too beautiful a day to have silly arguments.

A bit careless but mostly a bad default. One click shouldn't put passwords in files people commit. Anthropic should fix it.

Isn’t the simple answer shipping a local secret manager with Claude code?

Wouldn’t it make more sense to put in the user app data directory?

Great advice, hope it gets to more people

$19/user/month for secret scrubbing? What a rip off

Use this instead for free https://github.com/awslabs/git-secrets

It doesn’t matter if they should stay local, day 1 security best practices say you don’t write secrets to files, ever - especially without you even knowing!

This is such a typical blame the user response. You realize if I’m a sysadmin managing fleets of machines, this is an actual wake up in a cold sweat nightmare, even if those files never leave disk? In the past it was less a big deal, way bigger now that your machine god will just download packages and libs that have upstream malware that aggressively scans the file system for stuff like this. guess where it’s going to look first?

have more humility. jesus.

Coding is solved. Bugs not solved yet. Fix incoming

You guys need a pr team. All the communicate from anthropic seems to screw itself somehow...

> 2. Permission rules are old hat. Everyone should be using auto mode instead. It is safer

Instead of telling people they're holding it wrong, make it safe to be held however they could hold it.

> but we are looking into what we can do to prevent this.

Wait, I'm confused. You said yourself coding was solved, surely all you need to do is ask your AI God to come up with an idea, right?

01CPMD3174 former Claude Code customer here.

I’m wondering if it’s just me or does this response sound like it’s coming from someone who is out of touch with the reality of how people are using their product and instead of being empathetic, curious, and helpful is telling people in so many words it’s not our fault, you’re doing it wrong and “everyone” should be doing it the “right” way, which is how we do it.

I know it might come as a shock but not everyone who uses product has read the docs.

Also there is arguably nothing about using AI harnesses that’s “old hat” The technology came on the mainstream radar this year. Most people who use harnesses are still figuring out how to use them. And the rest of humanity probably doesn’t even know what the terms means.

Rather than telling everyone how they got it wrong, maybe next time you can elaborate on something like what “we are looking into what we can do to prevent this” means.

For the record, besides finding Claude overzealous and Anthropic’s usage limits relatively stingy (at least back in April when I dropped them), it was the arrogance of Anthropic’s staff and their public pontificating that led me to rolling with Codex, Gemini, and Qwen as my model stack.

You have to wonder how much of the AI backlash is driven by people not feeling how industry insiders communicate with them.

Anyways, we need good homegrown AI solutions. So, I’m hoping Anthropic follows through on helping prevent future incidents. And the other labs are paying attention so their leadership aren’t the next ones on HN playing defense when their products get called out.

Auto mode should be used by default? Is this the same mode that led to the Anthropic article discussing unintended model actions?

Ref: https://www.anthropic.com/research/investigating-unintended-...

No thanks.

I guess "you're holding it wrong" is a PR strategy now.

> Permission rules are old hat. Everyone should be using auto mode instead

"you are holding it wrong". No, it's not an excuse. Every mode should work correctly, or should not be selectable.

Aren’t you guys going to be one of the only two software developers employees in the nearest future? And autogenerate all software?

Then you can have it your way :))

> .claude/settings.local.json is meant to stay local. This is not a file you should check into source control.

Then don't put it in the fucking tree, you idiots.

No, .gitignore is obviously not enough.

So ... coding is solved but managing your git repo is not solved?

Can we take your responses here to represent your employer's position on this issue?

do you have a count on how many times claude has committed that file?

i bet most of the commited ones were done by claude because nobody else us gonna care to make it

Can secret scanning be enabled by default?

> Claude Code reads settings from four files, and an organization can also deliver managed settings from the claude.ai console. Each source has a scope: the set of people and projects a setting saved in it applies to, whether that’s only you, everyone in a project, or everyone in your organization.

The linked docs have an unmistakable slop aura, with the extreme overuse of commas that recent models seem to love. I don't blame people for not referring to them (also because, you know, the whole thing with AI is not having to read, think, or understand for yourself)

I don’t care how good you guys say auto mode is, I’m not giving your AI full permissions to my machine and the more you try to force AI psychosis onto me the closer I am to moving to something else.

Man. I'd prefer talking to Claude. He wrote the code.