HN

Comments (370)

• Menu

  bcherny
  Boris 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)
• Menu

  Aurornis
  Confusing headline. They scanned for repos where people had committed their .claude/ folder and local settings and then scanned those files for commands which contained keys or passwords.So pressing “Don’t Ask Again” by itself doesn’t expose passwords by itself. If you commit your local Claude settings and in those settings you have manually approved commands containing secrets directly in the command and then you publish the repo, that’s exposed.
• bvan
  Why bother with GitHub, anyway? Seems like an accident waiting to happen. Always has.
• Menu

  anatolii1309
  The root issue is not the button, it is that the allowlist stores the full command string, including whatever was in it. We ran into this ourselves: approve `curl -H "Authorization: Bearer sk-..."` once and that token sits in settings.local.json until someone happens to reread the file.Two rules that stuck for us: secrets go into commands only via env vars ($TOKEN, never the value), and .claude/ lives in the machine-wide global gitignore, not in the repo. With those, "Don't ask again" is fine and a commit has nothing to leak.
• Menu

  tsergiu
  I'm super paranoid about the level of access AI agents have. At the same time, I want them to take away the tedium of a bunch of tasks I'm required to do, and it sucks to have to micromanage them.The best solution I've been able to come up is using an ephemeral vm (on an isolated network) per task, using --dangerously-skip-permissions so it doesn't bother me. I couple that with an API proxy that lets me restrict the permissions it has to external services. So e.g. where a quickbooks API key gives the holder "god mode" access, the proxy lets the agent do certain read commands without confirmation, but all write endpoints except uploading receipts require confirmation on my phone before they'll be allowed to hit the quickbooks servers. I no longer need to trust that the agent will interpret my readonly wishes correctly.Tooting my own horn here, but this setup works incredibly well! I've been able to connect dozens of services safely where I absolutely do not trust giving raw, overpowered credentials or oauth integration to the agent directly. I actually just released the API proxy today at https://keycontain.com
• tim-projects
  Here is how to solve this:Use a private dev repo and do all your dev inside it.Releases go to a seperate public repoIn the private dev repo use a script which Cherry picks release files from a whitelist that you maintain in the public repo.Essentially, you define the files and folder structure of a release and that ensures every release looks great with no cruft and it's never going to have .secret.json in or whateverHardcoded secrets is seperate and you can have another script to grep for those
• Menu

  lacoolj
  This page is like 80% repeating itselfIf you post output from AI, please remember to edit before publishing
• tha_infra_guy
  This is one of the reason why we are building https://runeward.ioSandbox don’t scale anymore and secrets or confidential files shouldn’t be exposed to frontier models.
• Menu

  binarymax
  I keep all my creds in a password manager (1Password in my case) and Claude can’t see them - when a cred is needed it runs a script that calls the op CLI and I tap my fingerprint for access. Sometimes I need to do it a bunch of times for complex operations, but it’s worth it.
• ivan_gammel
  This may not be a popular answer here, but it works as expected. Basic security hygiene means that you use password manager CLI, SSH agent, at worst temporary git-ignored env files, so that the secrets would never appear in the command line and you would never pass them to Claude. And you git-ignore any local settings by default, to prevent accidental leaks. It is not hard thing to learn, many juniors I interviewed know this. Developers who like to shoot themselves in the legs should pay the price. People who hire careless workers and do not put them in compliant environment should pay the price too.
• tomrod
  More and more, I want a hard sandbox on these. For those of a similar security mindset, how are you sandboxing?
• tyingq
  is it just doing a string comparison? store a hash instead?
• ohyes
  This doesn’t seem like the right way to use secrets with an AI agent, in general.I always have it write a script and then write the secret to a different file myself, then instruct the agent to use the secret file in the script. That way the secret never goes through an external entity.I had thought this was common sense but now I’m realizing of course it isn’t, we have people with minimal experience using these tools and they don’t even consider that sending their bank password (or whatever) to a third party (even a relatively trustworthy one) is extremely risky.
• Menu

  thierryzoller
  Was reported as BUG on Dec 5, 2025 to Anthropic and automaticaly closed.https://github.com/anthropics/claude-code/issues/13106
• tiku
  Why does git even allow easy hidden file adding? It should be hard to add a .folder so noobs won't do that.
• Menu

  saidnooneever
  please dont forget basic operational security when using LLMs. they dont do everything for you. you can ask them to do all sorts of stuff, that doesnt mean you should.secrets, encryption, publishing to public internet, scanning for vulnerabilities in your packages etc. etc. you need to take your own responsibility for and never rely on some bot automation or third party.that includes if its important projects not relying on scanning tools but opening files yourself and verifying what's in there.read things before you put them in a place where everyone can see them forever....this is basic stuff. you guys did it beforen LLMs surely.YOU are responsible. not Claude, not any external vendor, not any downloaded script. You as a person.
• algonney
  From my point the best way is to give the AI all the permissions every thing that he needs to not stop on the middle of his work and after he done from the project you should change all the secrets api's, database whatever and by that you will be on the safe side.
• Menu

  andirk
  This is an issue because it is popular, not because it is novel.Review your code before committing. Do code reviews on PRs.
• theapiartist
  This could easily be prevented with credential management tools built specifically for ai agents.Tools like AgentSecrets, infiscal, Doppler. People just don't want to invest in securing their credentials, maybe because the majority don't realize that credentials are the crux of inter software communication. It's literally access to your services.
• zahlman
  I feel like pointing out, there are quite a few sorts of projects that can be developed without requiring any secrets (at least until publishing time, and that's something you really don't need an LLM to do for you once the process is established).
• Menu

  qezz
  > Is it public? > > Search your GitHub organization for .claude/settings.local.json and .claude/settings.json. Each hit is a file anyone can read right now. So, it's not necessarily "public", it's simply in the repository, and whether it's actually public or not depends on the repository settings.Or am I missing something
• nunez
  This is why you ALWAYS run gitleaks as a pre-commit hook, agent or not. It's saved me from myself so many times.
• anon
  undefined
• Menu

  skeledrew
  According to Claude docs, settings.local.json isn't to be committed. This is just people being the usual sloppy with secrets in repos, not something particular to Claude or AI in general.
• kristopolous
  here's what they look like btw https://github.com/Marius0G/iDrip/blob/2d79c54fb22025aaa8cf6...I mean it'd be crazy if this worked:https://github.com/search?q=path%3A**%2F.claude%2F*.json+CLI...oh look..
• 0xbadcafebee
  The first extension I add to any coding agent is one that redacts or rejects any read/write of a secret or credential or credential file. It's annoying, and the agent can work around it, but better to add a weak guardrail than none at all. Best is to not give it access to any secrets, but that's not always possible.Here's a few for Pi: https://pi.dev/packages/@k3_2o/pi-secrets https://pi.dev/packages/@spences10/pi-redact https://pi.dev/packages/keyshroudA couple for OpenCode: https://github.com/boxpositron/envsitter-guard https://github.com/kenryu42/cc-safety-net https://github.com/inkdust2021/opencode-vibeguard
• Menu

  GeoAtreides
  "git add . " considered harmful
• flufluflufluffy
  This just in checking your secrets into source control exposes your secrets!
• anon
  undefined
• GaryBluto
  People chose to upload a file containing their password and make it publicly accessible, I don't see a problem here.
• teejaypeeps
  The article reads as though an LLM wrote it
• semiquaver
  The solution, ironically, is always run in YOLO mode
• ry504
  Relatable lol. Personal privacy and security goes out the window when you go full Claude
• Menu

  cluckindan
  The irony that the article is written with Claude…
• mococa
  Plain text secrets? Super rookie mistake!
• Menu

  system2
  I still don't understand why people are using GitHub for their vibecoded projects. Just install git locally on your own NAS and control it there. What a weird fetish to publish online.
• Menu

  vcryan
  This is also an example of how someone's personal settings don't belong in a source code repo at all.I find it pretty annoying when someone commits their harness specific files into a repo - put that stuff under $HOME/.claude/
• Menu

  jedisct1
  If you really need to commit private files to GitHub, use Turbocrypt https://github.com/jedisct1/turbocrypt/blob/main/docs/git.md
• globular-toast
  Once again, devs shocked when random number generator has unpredictable results.
• ankur_misra
  [flagged]
• mstaoru
  [dead]
• JulianPaul
  [dead]
• haukebri
  [flagged]
• haifeng
  [flagged]
• Savlume
  [flagged]
• fiveapi_dev
  [flagged]
• klas_segeljakt
  [flagged]
• byoungyoung
  [flagged]
• no1guangming
  [flagged]
• sick_of_slop
  [dead]
• Menu

  rvz
  Vibe coders in open source proudly don't read the (slop)code and place all their agents in autonomous loops without them knowing that Claude leaked their passwords and environment variables on GitHub.This incident would have been caught in an open source harness. This one is closed source malware, and you don't know what Claude Code does internally to behave like this.Yet another reason why you cannot trust a closed harness.
• Menu

  fuckaiagi
  [flagged]