gitignore: cover config/*.env, which the .json rule never did - #55
Merged
Conversation
Found on the MacBook today: config/grok.env, untracked, unignored, holding a live key, in a checkout of a PUBLIC repo. One `git add -A` away from the same leak as 2026-07-09. Neither existing rule covered it. `config/*.json` is scoped to JSON, and the bare `.env` rule matches a file named exactly ".env" - not "grok.env". So the directory whose own comment says "Local machine configs hold live API keys - never commit" was protecting one file extension and silently not the other. That is the sibling trap: a rule was written for one variant, the variant it was written against stayed safe, and nobody checked whether its neighbour was covered. Verified by execution rather than by reading - `git check-ignore -v` resolves config/grok.env to this rule. Product fix rather than a local one: any user who drops a per-agent .env into config/ has the same exposure today, and a .git/info/exclude on my machine would fix it for exactly one of us.
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
This was referenced Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
config/*.envand*.envadded to.gitignore.Why, and it is not hypothetical
Checking my own IAK checkout after @claudemm flagged local patches on the Mini, I found
config/grok.env— untracked, unignored, holding a live key, in a clone of a repo that is public. Onegit add -Acommits it. That is exactly the 2026-07-09 leak, which we already paid for once in a key rotation.Neither existing rule covered it:
config/*.jsonis scoped to JSON. The.envfile sat right beside the files that rule protects..envrule matches a file named exactly.env. It does not matchgrok.env.So the block whose own comment reads "Local machine configs hold live API keys - never commit" was protecting one extension in that directory and silently not the other.
The pattern, because we hit it twice today
This is the sibling trap. A rule gets written for one variant, the variant it was written against stays correct, and nobody checks the neighbour. The other instance today was in CodeWatch:
thinkoff_greenwas corrected for the light theme and its near-twinthinkoff_green_lightkept the dark value, shipping 21 call sites at 2.6:1 for weeks. Same shape, different file.Worth a habit: when adding a protective rule, ask what else lives in the directory it protects.
Verified by execution, not by reading
Created the real filename in a worktree, confirmed the rule resolves to it, removed it again.
Why a PR and not a local exclude
I have already closed the hole on my own machine via
.git/info/exclude, so nothing is urgent for me. But that fixes it for exactly one of us. Any user who drops a per-agent.envintoconfig/— which is the natural place to put it, next to the.jsonconfigs we tell them to put there — has the same exposure right now. Per the dogfood directive this belongs in the product with a working default, not in my checkout.Not touched: the local modifications and stashes on the Mini that @claudemm flagged, and the ones on my own checkout (
scripts/codex-webhook-supervisor.sh, a one-line diff, plus a WIP stash). Those need a look at what they actually do and are @Petrus's call — one of them backs a running process.