oooh time to pull back the image again :3
The “nothing new, devs always commit secrets” take misses the bit that makes this one nasty: the file isn’t a .env someone chose to commit, it’s an agent settings file that silently accumulates the exact commands you approved, secrets included, and then gets accidently committed with the project because it lives in the repo, so it ends up publically exposed. YSK that’s a different failure mode to a one-off .env leak.
If you use Claude Code (or any coding agent, tbh), the practical fix is boring but it works: rotate anything that was in that file — deleting the file from the repo doesn’t un-expose it, it’s already scraped — then check git history, because the secret is still in there unless you rewrite it. Add settings.local.json to .gitignore, run a secret scanner like gitleaks in pre-commit, and stop using ‘don’t ask again’ for commands that echo tokens or passwords. Also audit the approved-commands list now and then, and keep tokens scoped as tightly as you can so a leak like this is annoying rather than catastrophic. FYI, GitHub’s secret scanning will catch some of this after the fact, but it’s no substitute for not committing the file in the first place.
I don’t understand why people trust LLMs.
Claude Code is not a LLM. It’s a regular application communicating with an LLM. It might be very vibe coded, seeing who it is written by, but it’s not an LLM that’s the problem here.
It’s just bad application design.
They don’t know how any of it works, and have no reason to ever learn now that they have a magic box, so of course they’re going to do whatever the magic box tells them as long as the magic box gives them what they want.
@davidagain Short answer: LLMs “push all our Darwinian buttons” (Sherry Turkel), the ones that make us social beings.
Devs accidentally committing secrets and forgetting to gitignore env files is nothing new, this is just a new surface. It’s why secret scanning is such an important part of a CI/CD pipeline.
a high entrop for any data going out from that blind CLI should be banned without exception. The user then needs to approve. its the responsibility of Anthropic.
I can only speak anecdotally, but from what I’ve seen firsthand the user does need to approve. In fact, the user needs to approve almost everything, unless they choose to put the CLI into “auto-mode” which should just be assumed is at one’s own risk.
In regard to
settings.local.jsonI’ve only ever seen it automatically created gitignored. I’m not saying it’s not possible for the user to prompt in some way to intentionally or accidentally bypass that, but still.At some point this honestly isn’t Anthropic’s problem. And a developer that takes the stance of “privacy and security is the responsibility of my toolkit” is one that is either very green, or reckless.
it’s a bit tedious in some ways but I really liked working with GitHubs secret system. As long as you ensure nothing changes in the GitHub run system you could use various key signing mechanisms or even uploads to service providers like AWS with out sharing via dot files or user configuration only files that end up being committed to the repo.
What the fuck is this website?
Are they ripping off HN and AI summarising their posts our what
https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again
is this the original?
This is what I thought people referenced for over a decade whenever they mentioned HN because no one pointed me to the actual HN.
y combinator was founded by sam altman and is really mostly AI schill and very boring nowadays
The slop is annoying but it’s getting better.
I didn’t look at hn for half a year because every post was about AI. But now interesting things are popping up again.
That explains why LLMs are so stochastic.
