Fix 'API Key Not Found in Cookies' Error

TL;DR

• API key not found in cookies almost never means your key is wrong. It means the browser app that stored your key in a cookie can't read that cookie back.
• The usual culprit: third-party cookies are blocked. Safari, Brave, Firefox, and every Incognito window block them by default — so the cookie holding your key silently never persists.
• Fast fix: allow cookies for the exact app domain, sign out and back in, then re-paste your key. Different browser or Incognito? That's why it "disappeared."
• Permanent fix (for developers): stop trusting the cookie jar. Send your key in an Authorization: Bearer header to a stable endpoint. No cookie, no cookie problem.

If you landed here because a guide told you this is a "Cursor" or "Windsurf" error — it isn't. This message comes from browser apps that keep your API key client-side, and the fix has nothing to do with your IDE.

What does "API key not found in cookies" actually mean?

It means the app expected to find your API key inside a browser cookie, checked, and the cookie wasn't there. Your key is probably fine. The storage that held it is what broke.

Here's the mechanism. Some web apps — AI chat frontends, reverse-proxy dashboards, a few SaaS consoles — don't want your key on their server. So when you paste it, they save it to a [cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies) (or a cookie-backed session) in your own browser. Every request then reads the key back out of that cookie. When the cookie is missing, blocked, expired, or scoped to a domain you're not currently on, the read returns nothing. You get API key not found in cookies.

So this is a client-side auth-state error, not an "invalid credentials" error. Nobody rejected your key. The app just couldn't find it to send.

Which apps throw this error — and why it's not your API key

Any browser app that stores your API key in a cookie can throw it. That's the honest answer, and it's worth stating because the top-ranked guide for this query blames IDE tools like Cursor, Windsurf, and Cline — with specific version numbers that don't correspond to a real cookie-based error. Those tools store keys in local config files, not browser cookies.

Where you actually see API key not found in cookies:

The common thread: your key never reached a server-side account. It's sitting in your browser, and your browser lost track of it. That reframes every fix below — you're not fixing a key, you're fixing cookie storage.

Why does the API key cookie keep disappearing?

Because modern browsers block third-party cookies by default, and the cookie holding your key is often treated as one. This is the root cause most "clear your cache" guides skip.

Look at the defaults. They changed under everyone's feet:

So the same key that "works on my laptop" fails in a private window, on a locked-down work browser, or after a browser update flipped a privacy default. The handshake looks like it completes — the app just can't write or read the cookie afterward.

A few more reasons the cookie goes missing:

• You cleared cookies (or used "clear browsing data") — the key cookie went with everything else.
• Different browser or device — cookies don't sync across them, so the key isn't there.
• Wrong domain or subdomain — a cookie set on app.example.com isn't visible on example.com, and vice versa.
• System clock drift — cookies carry an expiry timestamp. If your clock is off by minutes, the browser can treat a fresh cookie as already expired.
• SSL-inspecting corporate proxy or VPN — some rewrite or drop Set-Cookie headers, so the cookie never lands.

How do I fix "API key not found in cookies" right now?

Work down this list — the first two fix most cases in under a minute:

1. Allow cookies for the app's exact domain. In Chrome/Edge: Settings → Privacy and security → Third-party cookies → add the app's URL under "Allowed to use third-party cookies." In Safari: Settings → Privacy → uncheck "Prevent cross-site tracking" (or add a site exception). In Firefox: shield icon in the address bar → turn off Enhanced Tracking Protection for that site.
2. Sign out, sign back in, then re-paste your key. This forces the app to mint a fresh session and write a clean cookie. It's the auth-state equivalent of turning it off and on again.
3. Leave Incognito/Private mode. These block third-party cookies by design, and nothing persists after you close the window. Use a normal window and re-enter the key.
4. Disable ad blockers / privacy extensions for that site. uBlock Origin, AdGuard, and privacy add-ons can block the subdomain the cookie rides on. Whitelist the app, reload, re-enter the key.
5. Check your system clock. Turn on automatic date/time so NTP keeps you in sync. A drifted clock silently expires good cookies.
6. Confirm you're on the exact URL the key was saved on. If you saved the key on app.tool.com, a cookie won't show up on tool.com. Match the subdomain.
7. Regenerate the key on the provider dashboard. If a teammate rotated or deleted it, the cookie now points at a dead key. Create a new one, paste it, done.

If you're on a corporate network and none of this sticks, test on a phone hotspot for two minutes. If it works there, an SSL-inspecting proxy is eating your cookies — ask IT to bypass the app's domain.

How do I stop this error for good?

Stop depending on a browser cookie to carry your key. If you control the code, send the key in a request header instead — cookies are optional, headers are not.

Cookie-stored keys are fragile by design: they live in one browser profile, they inherit that browser's privacy rules, and they vanish on a cache clear. Header-based auth sidesteps all of it. The key travels in the request:

curl https://api.velokey.ai/v1/chat/completions \
  -H "Authorization: Bearer $YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

No cookie jar, no third-party cookie policy, no Incognito surprise. The same call runs from a script, a server, a CI job, or a backend that your frontend talks to — none of which have the cookie problem in the first place. If you're building a browser app, the durable pattern is to keep the key on your own backend and have the browser call *your* server, not paste a raw provider key into a client-side cookie.

This is also why API gateways don't hit this error. A gateway like [Velokey](https://api.velokey.ai) gives you one key that reaches many models — [GPT-5.6](/model/gpt-5.6), [Claude Opus 4.8](/model/claude-opus-4-8), [Claude Sonnet 5](/model/claude-sonnet-5) — through a single OpenAI-compatible endpoint, and that key rides in the Authorization header every time. There's no cookie to lose. If you were pasting a provider key into a chat frontend just to try a model, calling a stable endpoint directly is both simpler and harder to break. For the pricing side of that, see our Claude API pricing guide; for a full walkthrough, how to call an API with a key covers the setup end to end.

Quick fix reference

Frequently Asked Questions

Is "API key not found in cookies" specific to one app?

No. It's a generic message from any browser app that stores your API key in a cookie — AI chat frontends, reverse-proxy dashboards, and some web playgrounds all use this pattern. Guides that pin it to a single IDE are guessing. The fix is the same regardless: repair or replace the cookie holding your key.

Will clearing cookies delete my API key permanently?

No. Your key lives on the provider's dashboard, not in the cookie. Clearing cookies only removes the local copy the app was reading. You'll be signed out and asked to paste the key again, but the key itself is intact. Copy it from the provider before you clear, so you can re-enter it.

Can Incognito or private mode cause this error?

Yes, reliably. Incognito, Private, and InPrivate windows block third-party cookies by default and wipe everything when you close them. If you saved the key in a private window, it's already gone. Switch to a normal window, re-enter the key, and it will persist between sessions.

Does a VPN or corporate proxy trigger it?

It can. An SSL-inspecting corporate proxy or some VPNs rewrite or strip the Set-Cookie header, so the key cookie never lands in your browser. Quick test: switch to a phone hotspot for a minute. If the error clears, the network is the cause — ask IT to add the app's domain to the inspection bypass list.

Does this error affect server-side API calls?

No. Server-to-server calls send the key in an Authorization header, and there's no browser cookie involved, so this error can't occur there. It only shows up in browser apps that chose to store your key client-side. Moving auth into a request header is exactly why backends and scripts never see it.

Why don't API gateways or aggregators have this problem?

Because they authenticate with a header, not a cookie. You send Authorization: Bearer <key> on every request to a stable endpoint, so there's no browser cookie to block, expire, or clear. That's the structural reason a gateway call keeps working across browsers, private windows, and locked-down networks where a cookie-based frontend quietly fails.