Your Lovable API key stopped working, and when you went to look at it, it was not in your list of access tokens any more. Nothing you did caused that.
Since 25 July 2026, Lovable revokes a workspace API key automatically when it turns up in a public GitHub repository. The changelog wording is unambiguous: "GitHub detects the key and notifies Lovable, and the key stops working right away."
TL;DR
Lovable Labs is now a GitHub secret scanning partner, so a leaked workspace API key is killed within moments of the push. That's a genuinely good default. It also has three sharp edges: nothing blocks the commit, private repositories get no cover at all, and the alert never appears in your repository's Security tab because partner alerts skip it entirely. The email is your only signal.
What actually happened
The full changelog entry, from 25 July 2026:
"If a workspace API key is committed to a public GitHub repository, Lovable now revokes it automatically. GitHub detects the key and notifies Lovable, and the key stops working right away. The person who created it, along with every workspace owner and admin, gets an email naming the key and linking to the GitHub alert. Every workspace API key is covered automatically, and there's nothing to set up. A revoked key cannot be restored, so create a new key to replace it. Revoked keys no longer appear in your list of access tokens, and these emails are always sent, regardless of your email preferences."
Two lines in there explain the confusion people arrive with. A revoked key cannot be restored, and revoked keys no longer appear in your list of access tokens. So the failure looks like the key was never there. If the email went to a workspace owner who is not the person debugging, or landed in a promotions folder, there is nothing in the Lovable UI that says a revocation happened.
The email cannot be turned off, and that is deliberate
Lovable sends these "regardless of your email preferences." If you have muted Lovable notifications and your key still died, go and look for that email. It names the specific key and links to the GitHub alert, which tells you which commit exposed it.
Fix it in the right order
Find the commit, not just the key
The email links to the GitHub alert, which points at the commit. Open it. You need to know what else was in that file, because a .env committed by accident rarely contains one secret. Your Lovable key is the one that got revoked for you. Everything beside it is still live.
Create a replacement key
There is no undo, so this is the only path forward. Generate a new workspace API key and update wherever the old one was configured. Do not put it back in the repository.
Rotate every other secret in that commit
Supabase keys, Stripe keys, OpenAI keys, database URLs. Most of these have no partner arrangement with GitHub, so nobody revoked them on your behalf and nobody emailed you. Assume anything that was in a public repo is compromised, however briefly it was up.
Understand that deleting the commit does not help
Scrapers watch GitHub's public event firehose continuously. A secret that was public for ninety seconds should be treated as public forever. Rewriting history is worth doing for tidiness, and it is not a substitute for rotation. Our walkthrough on fixing Lovable API key exposure covers the history-scrub and rotation order for the frontend-bundle case, which is the other common way a Lovable project leaks.
The three gaps this leaves open
The revocation is a real improvement. It is also narrower than the announcement makes it sound, and the boundaries matter because they decide whether you are covered at all.
1. Nothing stops the commit
GitHub has a feature that blocks a push containing a secret before it lands. It is called push protection, and it is the difference between a leak and a near miss.
lovable_api_key does not have it. GitHub's supported-patterns table lists Lovable Labs with the partner column set and push protection not set, which means the sequence is: you push, the key is public, GitHub tells Lovable, Lovable kills it. Every step of that happens after the secret is already readable by anyone watching.
Assume the key was used. Revocation stops future use. It does nothing about the window between the push and the revocation, and automated scrapers are measured in seconds, not minutes. If that key could read anything sensitive, treat it as read.
2. Private repositories get nothing
GitHub's docs are clear that secret scanning "runs automatically for free" on public repositories. For an organization's private or internal repositories it requires GitHub Secret Protection on GitHub Team or Enterprise Cloud.
So a Lovable key committed to your private repo is not scanned, not reported to Lovable, and not revoked. It sits there, valid, until you notice it yourself.
This is the opposite of most people's intuition. A private repo feels safer, so it gets less care, and it is precisely where the automatic safety net does not reach. Private is not the same as secret: every collaborator, every future collaborator, every integration with repo access, and anyone who ever forks it internally can read that file.
3. The alert never reaches your Security tab
This one surprises people who go looking for evidence. GitHub splits secret scanning alerts into two kinds. User alerts show up in the Security and quality tab of your repository. Partner alerts do not: GitHub's docs state they "are not reported in the Security and quality tab of the repository," because they are routed to the provider instead.
Lovable is partner-only. There is no user alert for lovable_api_key.
The practical effect is that from inside GitHub, nothing happened. Your Security tab is clean. The only record on your side of the fence is the email Lovable sent, and the alert link inside it.
Check yourself before it fires
The scan covers more surfaces than most people picture. GitHub's docs list issue descriptions and comments, pull request titles, descriptions and comments, wikis, and secret gists alongside your code. Pasting a key into a public bug report is a leak.
Five minute Lovable key audit 5
The same week, more people could see your secret names
A day before the revocation change, on 24 July 2026, Lovable also let workspace editors see the names of build secrets, read-only, so they can pick the right one when attaching a private npm design system. Values stay hidden, and adding, editing or deleting secrets is still limited to admins and owners. Nothing leaks from this on its own. It's worth knowing if you had assumed editors could see nothing at all, because the naming convention you chose is now visible to a wider group.
What this tells you about safety nets generally
Automatic revocation is the right default and Lovable deserves credit for shipping it. The lesson worth carrying is about the shape of the guarantee rather than the feature.
It is reactive, not preventive. It covers one credential type out of the handful in your project. It works in one repository visibility state out of two. And it reports through a channel your own tooling cannot see.
That is a fair description of nearly every automated safety net you will be offered. They are worth having. They are not worth planning around, because the moment your situation sits slightly outside the covered case, the net is not there and nothing announces its absence.
Why did my Lovable API key stop working?
If it was committed to a public GitHub repository, Lovable revoked it. Since 25 July 2026 Lovable automatically kills any workspace API key that GitHub's secret scanner finds in a public repo, and the changelog says the key stops working right away. The creator plus every workspace owner and admin get an email naming the key and linking to the GitHub alert.
Can I restore a revoked Lovable API key?
No. Lovable's changelog is explicit that a revoked key cannot be restored, so you create a replacement instead. Revoked keys also stop appearing in your list of access tokens, which is why the old key can look as though it simply vanished rather than being killed.
Does this protect keys in a private GitHub repo?
No. GitHub's secret scanning runs automatically and free on public repositories only; an organization's private or internal repositories need GitHub Secret Protection on Team or Enterprise Cloud. A Lovable key in a private repo is not scanned, not reported to Lovable, and not revoked. It stays live until you find it.
Why is there no alert in my repository's Security tab?
Because Lovable is a partner-alert-only provider. GitHub's docs say partner alerts are not reported in the Security and quality tab of the repository, since they go straight to the provider instead. Lovable's email is your only notice, so if it lands in spam or reaches a workspace owner who is not you, the key just quietly stops working.
Will GitHub block the commit before the key leaks?
Not for this secret type. Push protection is the feature that blocks a push containing a secret, and GitHub's supported-patterns table shows no push protection for lovable_api_key. The commit lands, the key is public, and the revocation follows afterwards. Treat the key as having been readable.
What else does GitHub secret scanning look at besides code?
More than most people expect. GitHub's docs list issue descriptions and comments, pull request titles, descriptions and comments, wikis, and secret gists alongside repository code. Pasting a key into a bug report on a public repo counts as leaking it.
Find the Keys Nobody Revoked For You
Lovable kills its own leaked keys. Your Supabase, Stripe and OpenAI keys have no such arrangement. CheckYourVibe reads your deployed app and tells you which credentials made it to the browser.