The discussion centers on whether Claude Code's 'Don't Ask Again' feature is at fault for leaking secrets into public repositories or if the issue stems entirely from user negligence in committing local settings files. Conversely, defenders argue that manual review is fundamentally unsustainable at scale and that the industry must shift toward automated approval or robust sandboxing despite current flaws.
429 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4awslabs
git-secrets
Shell2015–2025
awslabs / git-secrets
git-secrets
Prevents you from committing secrets and credentials into git repositories
20Distinct people
23Mentions
0Explicit recommenders
13.4KGitHub stars
What to know before exploring
What it is
Prevents you from committing secrets and credentials into git repositories
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- trufflesecurity/trufflehog · linked in 4 of the same discussions
- michenriksen/gitrob · linked in 2 of the same discussions
- sirwart/ripsecrets · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
Mentions over time
HN mentions by year23 dated mentions
Observed mentions: 2015-12-11 00:33:15 UTC to 2025-06-16 10:39:27 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
23 sources2R2rsf·Jun 16, 2025
perplexity offered me those:
https://github.com/awslabs/git-secrets
https://www.infracloud.io/blogs/prevent-secret-leaks-in-repo...
https://www.reddit.com/r/git/comments/1h1r0ep/best_practices...
In addition GitGuardian cost something around $220/year per developer which is not too bad
In Ask HN: Prevent Secrets from Committing to ReposPrevents you from committing secrets and credentials into Git repositories
3 points · Open discussionI use one a git pre-commit hook that according to my notes i copied from here (at some point in the past, it may have changed since then):
https://gist.github.com/czardoz/b8bb58ad10f4063209bd
Then adapted with a better regex for secret keys I got from here: https://github.com/awslabs/git-secrets/blob/80230afa8c8bdeac...
(I think maybe I was getting false positives before)
In What happens when you leak AWS credentials and how AWS minimizes the damageSearch your existing code for secrets. Review all your commits before pushing.
Some tools can help with that:
https://martinfowler.com/articles/session-secret.html
https://github.com/trufflesecurity/trufflehog
https://about.sourcegraph.com/blog/no-more-secrets
https://github.com/Yelp/detect-secrets
https://docs.github.com/en/developers/overview/secret-scanni...
https://github.com/godaddy/tartufo
https://github.com/GitGuardian/ggshield
https://github.com/awslabs/git-secrets
https://github.com/sirwart/secrets
https://thoughtworks.github.io/talisman/
https://gitleaks.io/
In GitHub access token exposureI worked for a big startup last year and was on a contract deadline for integrating a vendor framework into a React Native app.
It was taking too long to get a new temp demo license key and GitHub search with clever filters helped me track down a demo key that was recently uploaded to a test repo.
This is also why I use git-secrets in my repos.
https://github.com/awslabs/git-secrets
In Toyota suffered a data breach by accidentally exposing a secret key on GitHubThere are a ton of them, here are a few:
https://martinfowler.com/articles/session-secret.html https://github.com/trufflesecurity/trufflehog https://github.com/awslabs/git-secrets https://github.com/sirwart/ripsecrets https://thoughtworks.github.io/talisman/ https://github.com/michenriksen/gitrob
In Quickly find sensitive files in your GitHub repoAWS has their own as well https://github.com/awslabs/git-secrets
In Secrets: A command-line tool to prevent committing secret keys into your source- https://github.com/auth0/repo-supervisor
- https://github.com/awslabs/git-secrets
- https://github.com/trufflesecurity/truffleHog
- https://www.gitguardian.com/
- https://github.com/eth0izzle/shhgit
All these tools can be configured to scan the repositories and generate alert when credentials or API keys are encountered
In Ask HN: What are the best automated tools for keeping credentials out of GitHub?There are a few considerations on that one, but one very practical reason is the developer experience of dealing with false positives.
False positives are one of the big problems in secret scanning. Some partners issue credentials with patterns that make them very hard to distinguish from innocuous strings. For example, a Datadog token looks identical to a commit SHA. We would never block developers from pushing commits to GitHub just because they had 40 character hexadecimal strings in them!
GitHub's partnership approach works around the false positive problem by having the token issuer check whether a token is real and take action only if it is. However, this is a one-way communication from GitHub - the token issuer doesn't need to tell us whether the candidate secret we sent them was real or not, and in most cases we never know.
As a r
Read the rest
esult, we can't replicate the zero false positive experience in a pre-receive hook (i.e., before the commit is pushed to GitHub). There would also be performance considerations from making 30+ http requests as part of a pre-receive hook.
In future, we are looking at creating a pre-receive hook solution that focuses on patterns that have a very low false positive rate. There are already some open source solutions that do this (links below) - in fact the OP linked to one from his Twitter thread. If/when GitHub offer is, it will definitely be opt-in, rather than opt-out!
* https://github.com/thoughtworks/talisman/
* https://github.com/awslabs/git-secrets
Git-secrets Prevents u from committing secrets and credentials 12 Git repos
1 points · Open discussiongit-secrets from the AWS team: https://github.com/awslabs/git-secrets
In CLI tool that finds secrets accidentally committed to a Git repo (2017)Showing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.