alt Hacker NewsBoris from the Claude Code team here. Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this.
That said, a few thoughts:
1. .claude/settings.local.json is meant to stay local. This is not a file you should check into source control. We automatically gitignore it when Claude creates the file, so in this case the files were manually created and checked in (docs: https://code.claude.com/docs/en/settings)
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. Auto mode is enabled by default and is included for free in all plans.
3. Regardless of what agent you use, you should have secret scanning enabled. GitHub and other source control hosts offer it. There are many threat models that it protects against and you should absolutely use it if you can. (see https://github.com/security/plans)
Replies
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.
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.
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.
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.
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.
This still presumably happens in auto mode as it asks for sensitive commands (and the default is "always allow," which saves it)
> 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 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.
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
> 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.
A bit careless but mostly a bad default. One click shouldn't put passwords in files people commit. Anthropic should fix it.
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.
> 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.
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.
> 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.
> 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)
You guys need a pr team. All the communicate from anthropic seems to screw itself somehow...
Can we take your responses here to represent your employer's position on this issue?
> 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?
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.
> .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.
Wouldn’t it make more sense to put in the user app data directory?
$19/user/month for secret scrubbing? What a rip off
Use this instead for free https://github.com/awslabs/git-secrets
Can secret scanning be enabled by default?
So ... coding is solved but managing your git repo is not solved?
[flagged]
[dead]
[flagged]
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"