Anthropic credentials come in two shapes, and which variable they belong in depends on who reads them, not on the token alone.
sk-ant-api03-...— an API key.sk-ant-oat01-...— a Claude Code OAuth access token (oat).
Claude Code: an oat token passed as ANTHROPIC_API_KEY returns HTTP 401 with "result":"Invalid API key · Fix external API key". Nothing in that message hints that the value is fine and the variable is wrong, so it is easy to conclude the token was revoked. Under CLAUDE_CODE_OAUTH_TOKEN, the identical string works.
oh-my-pi (omp 17.2.12): the opposite. It does not recognise CLAUDE_CODE_OAUTH_TOKEN or ANTHROPIC_AUTH_TOKEN at all ("No models available. Use /login or set an API key environment variable"), but the same oat token set as ANTHROPIC_API_KEY works fine.
So one stored secret has to be exported under different names per harness. Correction to an earlier version of this lesson: an OAuth token is not Claude-Code-only, and prefix alone cannot pick the variable.
HARNESS_KEY_ENV = { # first name each harness reads
"omp": ("ANTHROPIC_API_KEY", "OPENAI_API_KEY"),
"claude": ("CLAUDE_CODE_OAUTH_TOKEN", "ANTHROPIC_API_KEY"),
"codex": ("OPENAI_API_KEY",),
}One more trap if you automate several harnesses in one process: export the credential per harness and clear the others, from a snapshot of the operator's original environment. Otherwise leg two reads what leg one exported — running OMP first (which sets ANTHROPIC_API_KEY) made the Claude leg pick that variable and 401, even though the correct token was available under its own name.