> **Note on root cause:** The LiteLLM-side behavior described below is verified by reading the code on `main` and v1.86.0. The assumption that Claude Desktop's Code 3P tab sends `Authorization: Bearer sk-ant-oat-...` alongside `x-api-key: sk-<litellm-key>` is a strong hypothesis but **has not been confirmed by capturing the actual request headers**. It fits the symptoms (CLI and Cowork tab work with the same key; the error reports a token-not-found rather than a malformed key) but a maintainer or reporter should validate by capturing the headers Claude Code 3P actually sends before designing the fix.

## Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

Closest existing items, but **none cover this specific bug**: - #24436 / #24454 / #24539 — same OAuth-token-collision family, but those are about the *outbound* headers LiteLLM forwards to the upstream Anthropic API. This bug is in the *inbound* proxy auth itself (`user_api_key_auth`), which fails before any upstream call is made. - #24680 — same surface error message ("Unable to find token in cache or `LiteLLM_VerificationTokenTable`"), but unrelated cause (key cache…