Blog

OpenClaw: "No API key found for provider openai" after an upgrade

You bumped your instance to a newer OpenClaw build, and now every run dies before it starts with No API key found for provider "openai" — in the dashboard, "Missing API key for provider openai. Run openclaw doctor --fix to repair stale OpenAI model/session routes." Here's the cause: OpenClaw 2026.6.x moved the per-agent auth-profile store from JSON files to a SQLite database (openclaw-agent.sqlite), and it does not auto-import your old credentials on boot. The new gateway reads only the SQLite store, finds no openai profile there, and fails auth on every run — even though your key is still sitting in the old auth-profiles.json right next to it. The fix, in one line: run openclaw doctor --fix (it imports the legacy JSON into SQLite), then restart the gateway.

What you'll see
ProviderAuthError: No API key found for provider "openai".
Auth store: .../agents/main/agent/openclaw-agent.sqlite

Why an upgrade caused it

Nothing about your key changed. The store format changed underneath it. Before 2026.6.x, each agent's provider credentials lived in JSON next to the agent: auth-profiles.json (plus auth-state.json and, for Codex, sidecar OAuth files). Starting in 2026.6.x, OpenClaw keeps them in a SQLite store, openclaw-agent.sqlite. The upgrade does not migrate the JSON into SQLite automatically on first boot. So the sequence is:

  • The new binary starts and the gateway reads auth only from openclaw-agent.sqlite.
  • That store is empty for openai (your credential is still in the untouched auth-profiles.json).
  • Every run that needs the provider throws No API key found for provider "openai".

That is what the "repair stale OpenAI model/session routes" wording is pointing at: openclaw doctor --fix is the importer that copies the old JSON profiles into the SQLite store. It isn't a vague "try this" — it's the exact migration step the upgrade skipped.

One timing detail worth knowing: the auth-store cutover lands later than some other 2026.6.x store moves. An instance on an early 2026.6.x build can still be reading auth from JSON and be perfectly fine; the error only appears once a further upgrade crosses the auth cutover. So "it upgraded once before without this" is expected, not a contradiction.

Fix it (self-hosted)

Run these on the host or container where the gateway runs.

1) Confirm the cause

openclaw doctor

Look for a check named "Auth profile SQLite migration" (and possibly "Found N unreferenced legacy Codex OAuth sidecar credential file"). That confirms the JSON store hasn't been imported into SQLite yet — this page applies.

2) Run the importer

openclaw doctor --fix

This imports the profiles from auth-profiles.json into openclaw-agent.sqlite and renames the legacy files to auth-*.json.sqlite-import.<timestamp>.bak so they can't be picked up again.

3) Restart the gateway

Bounce the gateway so it re-reads the now-populated store. Send SIGTERM to the gateway process (PID 1 in a container: kill -TERM 1) or restart your service. After it comes back, the ProviderAuthError should be gone and runs should complete.

4) Verify every agent

If you run more than one agent on the instance, check each one. The --fix import is reliable when run by hand, but under automation it has been seen to import one agent's store and fail verification on another ("SQLite verification did not find imported profile"). If doctor still flags an agent after the fix, re-run openclaw doctor --fix and confirm that agent's store is populated before you call it done.

Don't do this

Don't wipe the SQLite store to "force a clean import." It's tempting to delete openclaw-agent.sqlite and let doctor --fix rebuild it from JSON. Don't — the importer is nondeterministic under automation, and clearing the store first has left a live agent with an empty auth store (zero profiles) when the re-import silently didn't run. Always import into the existing store; never clear it first. (And don't cp a live openclaw-agent.sqlite to "back it up" — you'll miss the -wal sidecar and copy a torn database.)

Stop babysitting your OpenClaw box

Fix it once — or stop fixing it for good.

Apply the checklist above and keep self-hosting, or skip the maintenance entirely: run your OpenClaw on managed hosting from $6.90/mo, starting with a 7-day free trial. We handle the stale locks, gateway restarts, version upgrades, and uptime — and you can import your existing instance in a couple of minutes. Cancel anytime.

Managed hosting — from $6.90/mo Your own hosted OpenClaw instance with automatic restarts and version upgrades. Starts with a 7-day free trial — import your current setup, keep your channels, cancel anytime.
$199 managed setup — optional Prefer we do it for you? One workspace configured end-to-end: first-run config, one 30-minute onboarding/debug session, and a 7-day follow-up. Limited weekly slots.
  • Managed hosting handles stale .jsonl.lock files, gateway restarts, and version upgrades for you
  • Import your existing OpenClaw setup in minutes — keep your channels and configuration
  • The optional $199 setup is scoped: no custom development, enterprise/SRE support, or unsupported self-hosting repair

If you would rather compare options first, review OpenClaw cloud hosting or see the best OpenClaw hosting options before deciding.

OpenClaw import first screen in OpenClaw Setup dashboard (light theme) OpenClaw import first screen in OpenClaw Setup dashboard (dark theme)
1) Paste import payload
OpenClaw import completed screen in OpenClaw Setup dashboard (light theme) OpenClaw import completed screen in OpenClaw Setup dashboard (dark theme)
2) Review and launch

Two lookalikes that are NOT this

The same error string shows up for two unrelated reasons. The fix above won't help either of them, so rule them out:

  • You only configured Anthropic and it still demands an OpenAI key. That's a separate upstream bug (openclaw/openclaw#66806): the agent looks up an openai credential even with a pure Anthropic-only config and no OpenAI provider anywhere. If you never added an OpenAI/Codex credential in the first place, doctor --fix has nothing to import — track the upstream issue instead of chasing a missing key.
  • You see refresh_token_reused (HTTP 401), not "No API key found." That's the split-store variant: a stray legacy auth-profiles.json the runtime keeps writing to while the gateway reads SQLite, so the two diverge and the refresh token goes stale. doctor --fix collapses the split, but if the token is genuinely reused you'll need to re-authenticate the provider interactively.

If instead your gateway is crash-looping on "Invalid config" right after the upgrade — not an auth error at all — that's the 2026.5.30 unified-OpenAI provider rename, covered in why an OpenClaw gateway fails to start with an invalid config after an upgrade.

How managed hosting handles this

This is a migration that should never reach a human. On managed OpenClaw hosting from Lobsterland, the store migration runs automatically once per version transition: when an instance crosses a store-format cutover, the platform runs the import and bounces the gateway for you, tracked by a per-instance marker so it self-heals this and any future SQLite cutover — and a same-version restart is a no-op. You bring your own model keys; you don't hand-run openclaw doctor --fix after every upgrade, and a routine version bump doesn't strand your credentials. If you'd rather not babysit auth-store migrations across upgrades, that's the gap managed hosting closes.

Import your current OpenClaw instance in 1 click

Frequently asked questions

Why does OpenClaw say "No API key found for provider openai" after an upgrade?

Because OpenClaw 2026.6.x moved the per-agent auth-profile store from JSON (auth-profiles.json) to a SQLite store (openclaw-agent.sqlite) and does not auto-import the old credentials on boot. The gateway reads only SQLite, finds no openai profile there, and fails auth — even though your key is still in the legacy JSON. Running openclaw doctor --fix imports the JSON into SQLite and clears the error.

What does "Run openclaw doctor --fix to repair stale OpenAI model/session routes" mean?

It points at the migration step the upgrade skipped. openclaw doctor --fix is the importer that copies your existing provider profiles from the legacy auth-profiles.json into the new openclaw-agent.sqlite store (renaming the old files to .sqlite-import.<timestamp>.bak). After it runs, restart the gateway so it re-reads the populated store.

Does openclaw doctor --fix delete my other provider credentials?

No — the import adds your existing profiles into SQLite; it doesn't remove other providers. The risk comes from a different move: do not delete openclaw-agent.sqlite first and rely on --fix to rebuild it. That clear-then-rebuild path is nondeterministic and has left a live store empty. Always import into the existing store.

I only configured Anthropic — why is OpenClaw asking for an OpenAI key?

That's a separate upstream bug (openclaw/openclaw#66806): the agent looks up an openai credential even in a pure Anthropic-only config with no OpenAI provider. If you never added an OpenAI or Codex credential, doctor --fix has nothing to import — this is not the store-migration case, so track the upstream issue rather than hunting for a missing key.

Will the No API key found for provider openai error come back on the next upgrade?

On a self-hosted instance it can recur on any upgrade that crosses a store-format cutover, unless something re-runs the import for you. On managed OpenClaw hosting the migration runs automatically once per version transition (tracked by a per-instance marker), so a routine upgrade doesn't reintroduce the error.

Cookie preferences