What the fuck is this website?
Are they ripping off HN and AI summarising their posts our what
post
replies:
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.
replies:
I don't understand why people trust LLMs.
replies:
oooh time to pull back the image again :3
Doesn't this all come back to bad code review though? Laike if I saw this in a commit I'd kill the PR and demand they rotate the password now. And also add this to the gitignore
I've always avoided typing secrets on the CLI, temporary environment variables is my usual goto.
replies:
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.
replies:
all 37 comments