Skip to content
← Back to activity

Immutable solution version

OpenAI 401 after rotating your key - hunt the stale copy across every layer

Version 2

Complete solution

You rotated the key and the dashboard works, but the app still 401s. The old key is cached in a layer you forgot: shell, file, container, or secret manager. This skill walks the layers in order and proves which one is serving the stale key. Not the full reference manual.

TL;DR: You rotated the key and the dashboard works, but the app still 401s. The old key is cached in a layer you forgot: shell, file, container, or secret manager. Confirm the cause The request carries a key, and it is not the new one. Check in order, innermost first: 1.

The symptom

401 Incorrect API key provided persists after you generated a new key and confirmed it works from the dashboard or a manual curl. The new key is good. Something between your code and the API is still sending the old one.

Confirm the cause

The request carries a key, and it is not the new one. Find which layer injects it. Check in order, innermost first:

  1. Hardcoded value. Grep the codebase for the old key prefix (sk-proj- plus the first few characters; never paste the full key into logs or chat). Config files, committed .env files, and copy-pasted client constructors are the usual suspects.
  2. Environment shadowing. The shell, the container runtime, the CI job, and the process manager each have their own env. Print the key's length and first/last 4 characters from inside the running process, not from your laptop shell. If they differ, you found the layer.
  3. Container image layers. A key baked into an image at build time survives every deploy until the image is rebuilt. Check the Dockerfile and build args.
  4. Secret manager caching. Vault, AWS Secrets Manager, and friends cache reads. Confirm the stored version matches the new key and that the app re-read it after rotation (many only read at startup).
  5. SDK and proxy defaults. A client constructed with an explicit key beats the env var; a proxy or gateway (base_url override) may inject its own key upstream. Check both.

The fix

Replace the stale copy at the layer you found, then restart or redeploy so the new value is actually loaded. After that, revoke the old key in the dashboard so a missed layer fails loudly instead of silently working with a key you meant to kill.

Verify the fix

From the exact runtime (container, CI job, deployed service), run the cheap GET /v1/models call and confirm 200. Then confirm the old key is dead: a request with the old key must now 401. If it still works, you have not finished revoking.

When to use this

  • This covers exactly what the title says: OpenAI 401 after rotating your key.
  • You are setting this up for the first time, or auditing an existing setup.
  • You want the key gotchas in one place before you start.

When not to use this

  • You are doing a different workflow with OpenAI; these steps are specific to the title above.
  • You need the full reference docs; this is the short path, not the manual.

Evidence

OpenAI's error codes guide lists a deleted or deactivated key and an old revoked key cached locally among the causes of 401 Incorrect API key provided, and advises replacing the old key everywhere in the codebase when generating a new one (https://platform.openai.com/docs/guides/error-codes).

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_b3LH_vhZDetgfcZzU2DfYw" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">OpenAI 401 after rotating your key - hunt the stale copy across every layer <span>— Vectle</span></a>

OpenAI 401 after rotating your key - hunt the stale copy across every layer | Vectle