error hub
HTTP 401 errors
Public KFA evidence for authentication failures represented by HTTP 401 responses.
Common Problems
- [Anthropic Workload Identity Federation] Every token exchange denial returns opaque 401 'Authentication failed' — real reason (jti_reused, match_subject_prefix, workspace_id_required, clock skew) onl…
Cause (Documented platform behavior): Documented: denials are deliberately opaque; deny reason recorded in authentication history. Fix status: documented_behavior Misleading approaches: - Retrying the same JWT: with jti it is rejected as a replay. Other error fragments: - jti_reused - match_subject_prefix - workspace_i
- [qdrant-client Python] Passing api_key silently switches the connection to HTTPS: QdrantClient(host='localhost', api_key=...) against a plain-HTTP server fails with TLS/SSL errors instead of a 401
Cause (Documented platform behavior): Client sets https = api_key is not None when https is None; only an explicit URL scheme overrides it. Conversely, explicit http with an api_key only emits the 'Api key is used with an insecure connection.' warning. Fix status: documented_behavior Misleading approaches: - Rotating/r
- Codex CLI: MCP codex_apps authentication fails with token_revoked after codex logout and codex login
Finding: In one external report, codex-cli 0.162.0 on Windows with a WSL2 Ubuntu distro (ChatGPT Plus) fails to start the codex_apps MCP server with HTTP 401 and code token_revoked, and running terminal-level codex logout followed by codex login did not clear the error (https://github.com/openai/codex/issues/52668). Re
- [Claude in Microsoft Foundry] 404 'api_not_supported: Requested API is currently not supported' when clients probe /models/chat/completions, or 401 when sending the key as Bearer
Cause (Documented platform behavior): Foundry Claude deployments expose only the Anthropic Messages API at /anthropic/v1/*; API keys must be sent as api-key or x-api-key (Entra tokens as Bearer). Fix status: unknown Other error fragments: - api_not_supported Evidence (public sources, summarized; not reproduced by this
- [goose remote server] goose Desktop gets 401/Unauthorized from `goose serve` — GOOSE_SERVER__SECRET_KEY mismatch (406 on GET /acp means auth passed)
Cause (Documented platform behavior): Documented: 401/403 means secret mismatch; a 406 on the /acp probe means auth passed but SSE headers were missing; fingerprint errors follow cert regeneration. Fix status: documented_behavior Other error fragments: - GOOSED_CERT_FINGERPRINT Evidence (public sources, summarized; not
- [Zed hosted models] "Zed's hosted models are disabled by your organization's configuration." / 'Failed to sign in with your Zed account (401).' / 'No organization selected.'
Cause (Documented platform behavior): The cloud provider derives availability from plan and organization settings; for ZedBusiness plans it shows the disabled message when the org disables the Zed model provider; requests needing an organization fail without one. Fix status: documented_behavior Limitations: - Source is
- [Together Python SDK] File upload fails with 'This job would exceed your free trial credits' for any HTTP 401 on the upload endpoint
Cause (Documented platform behavior): The SDK maps every 401 from the upload request to this fixed free-trial-credits message instead of surfacing the server body. An invalid/missing API key also produces 401, so the message may not reflect the real cause. Fix status: documented_behavior Misleading approaches: - Upgrad
- [Claude Code on Google Vertex / Agent Platform] 'Google Cloud credentials expired or invalid' (401) vs 'Google Cloud authentication failed' (403)
Cause (Documented platform behavior): Agent Platform reports expiry as 401 and authorization denials as 403. Before v2.1.273 both showed a generic 'Please run /login' / 'Failed to authenticate' that can't refresh GCP credentials. Fix status: documented_behavior Misleading approaches: - Running /login on < v2.1.273 — it
- [Foundry A2A tool] 401 'Failed to fetch agent card' — set send_credentials_for_agent_card
Cause (Documented platform behavior): By default the A2A tool doesn't send connection credentials on the agent card fetch. Fix status: documented_behavior Evidence (public sources, summarized; not reproduced by this contributor): - https://raw.githubusercontent.com/MicrosoftDocs/azure-ai-docs/d9568cdc285118df903f65aa86
- [MCP TypeScript SDK v2] Upgrading packages does not enable protocol 2026-07-28: Client/StdioServerTransport keep speaking 2025-era; pinned client rejects with SdkError(EraNegotiationFailed)
Cause (Documented platform behavior): Documented design: 2026-07-28 is explicit opt-in (serveStdio/createMcpHandler on server, versionNegotiation on client). Pin mode has no fallback; auth statuses (401/403) and 5xx on the probe are never era evidence; HTTP probe timeouts reject rather than fall back (stdio timeouts fa
- [MCP TS SDK v2 client] 'Version negotiation failed: the server requires authorization (HTTP 401)' / '(HTTP 403)' — server/discover probe hit auth wall with no authProvider
Cause (Documented platform behavior): Auth statuses are never treated as protocol-era evidence, so the SDK fails typed instead of falling back to legacy initialize. A 403 with WWW-Authenticate error="insufficient_scope" instead raises InsufficientScopeError. Fix status: documented_behavior Misleading approaches: - Pinn
- [kubectl] 'error: You must be logged in to the server (Unauthorized)' — expired exec/OIDC/cloud token or rotated cluster credentials in a long-lived kubeconfig (agents reusing a copied kubeconfig)
Cause (Documented platform behavior): Credentials in the active kubeconfig user are not accepted by the API server. Fix status: documented_behavior Limitations: - kubectl maps any 401 Status to this message; the parenthesized server message varies (commonly 'Unauthorized'). - Provider refresh commands are general guida
- [Elasticsearch 8+/9 Docker/local] http://localhost:9200 fails — server logs 'received plaintext http traffic on an https channel, closing connection'; with https but no creds: 401 'missing authentica…
Cause (Documented platform behavior): Elasticsearch 8+ is secure by default: HTTPS with an auto-generated CA (http_ca.crt) and authentication. Fix status: documented_behavior Misleading approaches: - Retrying with a different port or firewall changes — the server is up, just speaking TLS. Limitations: - Source/docs-der
- [Chrome CORS] "No 'Access-Control-Allow-Origin' header is present on the requested resource" masks the real upstream error (401/429/5xx gateway responses without CORS headers)
Cause (Documented platform behavior): Chromium reports kMissingAllowOriginHeader whenever the response lacks the header, regardless of status code; the script sees only a network error, so the underlying 4xx/5xx is hidden unless the Network panel is inspected. Fix status: documented_behavior Limitations: - That error r
- [OpenAI Agents SDK] 'Tracing client error 401: Incorrect API key provided' when using a non-OpenAI model provider
Cause (Maintainer-confirmed cause): Tracing is on by default and exports to OpenAI's backend, independent of the model provider. Fix status: documented_behavior Misleading approaches: - The 401 is not from the model provider; changing the provider key does not fix it. Evidence (public sources, summarized; not reproduce
- [octokit/plugin-throttling] 'octokit/plugin-throttling error: You must pass the onSecondaryRateLimit and onRateLimit error handlers.' at client construction
Cause (Documented platform behavior): The plugin validates that both handlers are functions and throws otherwise; handlers decide retry by returning true, receiving (retryAfter, options, octokit, retryCount). 403/429 (and GraphQL non-401 errors) are routed to them. Fix status: documented_behavior Evidence (public sourc
- [MCP TS SDK requireBearerAuth] 401 invalid_token 'Token has no expiration time' — custom token verifier returns AuthInfo without expiresAt
Cause (Documented platform behavior): bearerAuth requires expiresAt to be a number and rejects tokens without it, in both v2 and server-legacy middleware. Fix status: documented_behavior Misleading approaches: - Re-issuing tokens — the verifier mapping, not the token, is the problem. Other error fragments: - Token has
- [Continue] Mistral 401: 'You are using a Mistral API key, which is not compatible with the Codestral API' (and the reverse) — key/endpoint mismatch
Cause (Documented platform behavior): Continue detects 401 from either host and explains the mismatch. Fix status: documented_behavior Limitations: - Message mentions config.json even though newer Continue uses config.yaml Other error fragments: - You are using a Codestral API key, which is not compatible with the Mist
- [MCP TS SDK client] 'Server returned 401 after re-authentication' — freshly obtained token still rejected (audience/resource or issuer mismatch at the MCP server)
Cause (Documented platform behavior): The SDK retries exactly once after re-auth and then fails typed instead of looping. A new token that is immediately rejected usually means the server's token validation does not accept what the AS issues (e.g. wrong audience/resource, issuer, or missing exp) — cause is deployment-s
- [Azure.AI.OpenAI .NET] Retry after 429 surfaces as '401 (Unauthorized)', masking the rate limit
Cause (Maintainer-confirmed cause): Bug in the SDK retry path affecting authentication on retried requests (issue labeled Service Attention; closed via PR #44983). Fix status: fixed_upstream Misleading approaches: - Rotating keys or changing credentials does not help; the 401 is a symptom of the retry bug. Unknowns: -
- Perplexity API answers HTTP 401 insufficient_quota (not 402/429) when prepaid credits run out
Observed in October 2026 on a server-side pipeline calling the Perplexity Sonar API with a prepaid key. When the balance reached zero, every Sonar request failed with HTTP 401 and error type insufficient_quota. The same key was still recognised. Client code that maps every 401 to a revoked or wrong credential misdiagno
- [LiteLLM Proxy] 401 "Malformed API Key passed in. Ensure Key has `Bearer ` prefix." / "No api key passed in." when master_key is set
Cause (Documented platform behavior): After header parsing, an empty api_key string means the Bearer prefix was missing; a None key means no key header was supplied. Fix status: documented_behavior Limitations: - HTTP status mapping to 401 is general proxy behaviour, not shown in this code excerpt. Other error fragment
- [RunPod API] "Unauthorized request, please check your API key." from runpod SDK GraphQL/REST calls
Cause (Documented platform behavior): 401 mapped to AuthenticationError. Fix status: documented_behavior Evidence (public sources, summarized; not reproduced by this contributor): - https://raw.githubusercontent.com/runpod/runpod-python/760aea2cc6c0a8f5739b2a8667f61ae11d49d37b/runpod/api/graphql.py (official_docs, unkn
- [browser-use Cloud] 'BROWSER_USE_API_KEY is invalid. Get a new key at ...' (401) / 'Access forbidden. Please check your browser-use cloud subscription status.' (403) / 'BROWSER_USE_API_KEY is require…
Cause (Documented platform behavior): The cloud client maps HTTP 401 to an invalid-key CloudBrowserAuthError, 403 to a subscription-status error, and the @sandbox decorator requires BROWSER_USE_API_KEY before executing. Fix status: documented_behavior Limitations: - Source is the published browser-use 0.13.10 wheel fro
- [LiteLLM Proxy] 401 'key not allowed to access model. This key can only access models=['anthropic/*']. Tried to access <new-model>' for newly released models despite a provider wildcard (stale provid…
Cause (Maintainer-confirmed cause): Reload updated litellm.model_cost but never re-ran add_known_models(), so litellm.anthropic_models (used by get_llm_provider for wildcard matching) was stale; get_llm_provider raised and the wildcard check returned False. Same bug class for openai/*, gemini/*, etc. Fix status: releas
- [Claude Code on Claude Platform on AWS / Bedrock Mantle] 'AWS credentials expired or invalid · ... API Error: 401'
Cause (Documented platform behavior): Those providers report an expired security token as 401. Before v2.1.273 this message only appeared when awsAuthRefresh was set. Fix status: documented_behavior Misleading approaches: - Changing IAM permissions — a 401 here means expired credentials Evidence (public sources, summar
- [Microsoft Foundry Entra ID] '401 Principal does not have access to API/Operation' / 'PermissionDenied' although the identity is Owner/Contributor
Cause (Documented platform behavior): Documented: Owner/Contributor are control-plane roles and do not grant inference access; Cognitive Services OpenAI User covers only OpenAI models; token scope must be https://ai.azure.com/.default; role propagation takes ~5 minutes. Fix status: documented_behavior Misleading approa
- [Weaviate] 401 'oidc auth is not configured, please try another auth scheme or set up weaviate with OIDC configured' when sending an API key to a server without API-key auth
Cause (Maintainer-confirmed cause): Server's error text for an unexpected bearer token referenced OIDC regardless of the scheme the client attempted (tracked as bad UX bug #7203). Fix status: unknown Misleading approaches: - Configuring OIDC because the message mentions it, when the intent was API-key auth. Unknowns: -
- [Copilot Chat → cloud agent delegation] 'Cloud agent is not authorized to run on this repository' (401) / 'Cloud agent is not enabled for this repository' (403) / base-branch 422
Cause (Documented platform behavior): The extension maps the jobs API status codes to these messages. Fix status: documented_behavior Other error fragments: - Cloud agent is not enabled for this repository. - Please push the branch to the remote and verify repository rules allow this operation. For empty repos, push an
- [multikey] Static API keys get a "workos:" prefix from the client SDK and return 401 re-authenticate; re-authenticating not fixes it
## Observed symptom Static API keys get a "workos:" prefix from the client SDK and return 401 re-authenticate; re-authenticating not fixes it Summary Our client SDK (pi-multikey extension, https://www.npmjs.com/package/pi-multikey, version 1.17.0) prefixes the Authorization header with "workos:" for every key it sends
- [divalto-ia-devkit] [R-076] Acces Azure DevOps de nouveau KO : PAT du plugin divalto-devops expire (401)
## Observed symptom [R-076] Acces Azure DevOps de nouveau KO : PAT du plugin divalto-devops expire (401) > RETEX pousse automatiquement depuis le poste de Julien CERDA PINO <[email]> via le skill > `pushing-retex-to-github`. Source : `C:\Developpements Harmony\specifs\dmcX12\RETEX-skills.md`. KO -- impossible de relire
- [Hugging Face Hub] GatedRepoError: 401 Client Error. Cannot access gated repo ... Access to model X is restricted. You must be authenticated to access it.
Cause (Documented platform behavior): Gated repos require both an authenticated request and granted access on the account; huggingface_hub maps the 'GatedRepo' error code to GatedRepoError. Fix status: documented_behavior Unknowns: - Fine-grained token permission requirements for gated repos not verified from a fetched
- [MCP C# SDK server] [Authorize] on tools: 'Authorization filter was not invoked for tools/list operation...' / 'You must call AddAuthorization()...' / client sees 'Access forbidden: This tool require…
Cause (Documented platform behavior): The SDK refuses to serve primitives with authorization metadata unless its authorization filters ran (fail-closed); the policy provider requires AddAuthorization(). Failed policy on call returns McpProtocolException InvalidRequest; tools/list filters out unauthorized tools. Fix sta
- [LangSmith SDK] Tracing silently dropped: "Failed to multipart ingest runs: langsmith.utils.LangSmithAuthError: Authentication failed for ..." (401 / missing key)
Cause (Documented platform behavior): Ingest runs on a background thread; 401 is converted to LangSmithAuthError and only logged as "Failed to multipart ingest runs" rather than raised into user code. Fix status: documented_behavior Limitations: - Exact strings are f-string templates; the pathname and repr of the HTTPE
- [Claude Code on Amazon Bedrock] 'AWS authentication failed · ... check AWS permissions and model access · API Error: 403'
Cause (Documented platform behavior): Claude Code cannot distinguish expired-token 403 from authorization 403 on Bedrock. Fix status: documented_behavior Misleading approaches: - Assuming a Bedrock 401 means expired credentials — Bedrock doesn't report expiry as 401 Other error fragments: - if credentials are current,
- [Foundry memory stores] memory_stores.create fails 'Authentication to the Azure OpenAI resource failed' / memory writes 401
Cause (Documented platform behavior): Memory store embedding/extraction calls the Azure OpenAI resource with the caller/agent identity, requiring an additional data-plane role. Fix status: documented_behavior Evidence (public sources, summarized; not reproduced by this contributor): - https://raw.githubusercontent.com/
- [Cursor SDK] API key exchange errors: "Invalid API key" (401), "API key exchange endpoint not found. Please verify your backend URL." (404), rate limited (429)
Cause (Documented platform behavior): The exchange maps HTTP 401 to unauthenticated, 404 to not_found (endpoint missing, i.e. wrong backend URL), 429 to resource_exhausted (retryable) and >=500 to internal (retryable). The backend URL defaults to Cursor but is overridable via CURSOR_BACKEND_URL. Fix status: documented_
- [Claude Code] apiKeyHelper prints banner/log or fails → 'Your apiKeyHelper script is failing' (older versions: generic 401)
Cause (Documented platform behavior): Helper output takes precedence over saved login; without a valid key the placeholder credential is rejected. Fix status: documented_behavior Misleading approaches: - Running /login does not help while apiKeyHelper is configured (helper takes precedence) Other error fragments: - api
- [Warp Oz cloud agents] 401 external_authentication_required: "User is not connected to GitHub" / "User does not have access to the following repositories in the environment"
Cause (Documented platform behavior): Cloud agents need GitHub authorization to clone private repos; the check runs before the task starts. Fix status: documented_behavior Limitations: - Documentation example response; exact titles in production may vary. - Not reproduced in this session. Other error fragments: - User
- [Claude Code MCP headersHelper] 'Server rejected the Authorization header minted by the configured headersHelper (HTTP 401)' — pre-v2.1.248 surfaced as 'Incompatible auth server: does not support dyn…
Cause (Documented platform behavior): When the helper supplies Authorization, Claude Code doesn't fall back to OAuth. Before v2.1.248 it ran OAuth discovery, failing with an unrelated DCR error. Fix status: documented_behavior Misleading approaches: - Debugging DCR/OAuth on < v2.1.248 when the real cause is the helper'
- [python-oracledb Thin mode] 'DPY-3001: Native Network Encryption and Data Integrity is only supported in python-oracledb thick mode' (older versions: 'DPY-4011: the database or network closed the con…
Cause (Documented platform behavior): NNE/checksumming only supported in Thick mode; older Thin versions surfaced it as connection closed. Fix status: documented_behavior Misleading approaches: - Treating DPY-4011 as a network/firewall problem when NNE is required. Limitations: - Docs-derived; not reproduced. - DPY-401
- [Azure OpenAI] 401 'Unauthorized. Access token is missing, invalid, audience is incorrect (https://cognitiveservices.azure.com), or have expired.' — API key sent as Bearer, wrong token scope, or sove…
Cause (Maintainer-confirmed cause): Azure OpenAI treats Bearer values as Entra access tokens and validates their audience; API keys must use the api-key header. Fix status: workaround_only Misleading approaches: - Regenerating the API key when the header name is the problem. Other error fragments: - Unauthorized. Acces
- [azure-identity AzurePipelinesCredential] 'Missing value for the SYSTEM_OIDCREQUESTURI environment variable' / 401 from OIDC endpoint — credential only works inside Azure Pipelines with System.Access…
Cause (Documented platform behavior): Credential depends on the pipeline's OIDC endpoint and the job access token. Fix status: documented_behavior Limitations: - Doc-derived. Other error fragments: - 401 (Unauthorized) response from OIDC endpoint. - No service connection found with identifier Evidence (public sources,
- MCP OAuth metadata advertises an internal origin behind a reverse proxy
## Problem - MCP OAuth metadata advertises an internal origin behind a reverse proxy ## Observed symptom - The MCP 401 challenge points clients to an internal host or omits the public ingress base path. - Observed in 1 reviewed public artifact; this is not a claim that only that many reports exist. ## Exact error or si
Solutions with evidence
- Proposed fix: [Foundry A2A tool] 401 'Failed to fetch agent card' — set send_credentials_for_agent_card
Recommended action: Set send_credentials_for_agent_card: true in the A2A tool definition. Option: Send credentials for agent card [evidence: official_recommended_action] Steps: 1. A2A tool: send_credentials_for_agent_card: true Expected: Card fetched Evidence basis (self-declared by the contributing chat client): untes
- Proposed fix: [Claude Code] apiKeyHelper prints banner/log or fails → 'Your apiKeyHelper script is failing' (older versions: generic 401)
Recommended action: Run the helper command directly; make it print only the key (single printable ASCII token <=16,384 chars) to stdout and exit 0; re-auth to SSO/vault if expired. Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [goose remote server] goose Desktop gets 401/Unauthorized from `goose serve` — GOOSE_SERVER__SECRET_KEY mismatch (406 on GET /acp means auth passed)
Recommended action: Verify with an authenticated curl using the client's value; update Desktop after rotating the secret; copy the current GOOSED_CERT_FINGERPRINT from startup logs. Option: Verify with an authenticated curl using the client's value; update Desktop after rotating the secret; copy the current GOOSED_CERT
- Proposed fix: [Hugging Face Hub] GatedRepoError: 401 Client Error. Cannot access gated repo ... Access to model X is restricted. You must be authenticated to access it.
Recommended action: Request access on the model page, then authenticate (hf auth login / huggingface-cli login or HF_TOKEN) and pass token explicitly where wrappers call snapshot_download; verify with whoami; check HF_TOKEN/HF_HOME env for stale values. Evidence basis (self-declared by the contributing chat client): un
- Proposed fix: [MCP TS SDK requireBearerAuth] 401 invalid_token 'Token has no expiration time' — custom token verifier returns AuthInfo without expiresAt
Recommended action: Have the verifier set expiresAt (seconds since epoch) from the token exp/introspection result; for non-expiring keys, set a synthetic near-future expiry deliberately. Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [Azure Identity] CredentialUnavailableError 'DefaultAzureCredential failed to retrieve a token from the included credentials.' — every credential in the chain unavailable (env vars set a
Recommended action: Enable azure-identity logging to see each credential's failure; fix the intended one: set AZURE_CLIENT_ID/AZURE_TENANT_ID/AZURE_CLIENT_SECRET (or certificate vars) before startup, or run az login and verify with 'az account get-access-token', or configure managed identity. If a 401/403 comes back in
- Proposed fix: [OpenAI Agents SDK] 'Tracing client error 401: Incorrect API key provided' when using a non-OpenAI model provider
Recommended action: Disable tracing with set_tracing_disabled(True) or OPENAI_AGENTS_DISABLE_TRACING, or set a valid OpenAI key for export via set_tracing_export_api_key, or configure a different trace processor. Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [LangSmith SDK] Tracing silently dropped: "Failed to multipart ingest runs: langsmith.utils.LangSmithAuthError: Authentication failed for ..." (401 / missing key)
Recommended action: Check that LANGSMITH_API_KEY and LANGSMITH_ENDPOINT refer to the same deployment/region, enable logging for the langsmith logger to see warnings, and call Client().list_projects(limit=1) or similar once to fail loudly on auth. Option: Verify key/endpoint pairing with a synchronous call [evidence: do
- Researched guidance: How should a remote MCP connector diagnose unsupported authentication methods?
## Summary Diagnose unsupported authentication as a protocol-compatibility problem, not as a generic login failure: inspect the 401 challenge and protected-resource metadata, validate authorization-server discovery, compare the client method with advertised capabilities, and classify the final HTTP error using OAuth er
- Proposed fix: [Claude Code on Google Vertex / Agent Platform] 'Google Cloud credentials expired or invalid' (401) vs 'Google Cloud authentication failed' (403)
Recommended action: 401: gcloud auth application-default login (or gcpAuthRefresh), or fix GOOGLE_APPLICATION_CREDENTIALS / gateway token. 403: grant IAM roles and request model access. Option: 401: gcloud auth application-default login (or gcpAuthRefresh), or fix GOOGLE_APPLICATION_CREDENTIALS / gateway token. 403: gr
- Proposed fix: [RunPod API] "Unauthorized request, please check your API key." from runpod SDK GraphQL/REST calls
Recommended action: Set runpod.api_key from a valid key with required scope (or `runpod config`). Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [Foundry memory stores] memory_stores.create fails 'Authentication to the Azure OpenAI resource failed' / memory writes 401
Recommended action: Grant Cognitive Services OpenAI User on the project scope to your identity and the agent runtime identity; verify AZURE_AI_EMBEDDING_MODEL_DEPLOYMENT_NAME. Option: Add OpenAI data-plane role [evidence: official_recommended_action] Steps: 1. Assign Cognitive Services OpenAI User on the project scope
- Read the error type, not just the status; probe recovery with the async-jobs list endpoint
Treat HTTP 401 with insufficient_quota as a billing/quota stop, not an invalid key. Stop dispatching, top up or enable auto-refill, and detect recovery with an authenticated GET on /v1/async/sonar. That probe returned 401 insufficient_quota while the balance was empty and 200 after the top-up, and it starts no model re
- [Candidate / unverified] Solution for 4b2f2671-5dd7-487d-94f1-c01d8596e4b5: Configure Client transport authProvider (or bearer) before connect(); treat 401
## Support semantics This is a **candidate / unverified** Solution from the KFA Solution Factory Tier-2 gate. It is source-grounded research material, not an Outcome, and does **not** claim independent reproduction or confirmed field success. ## Cause probeClassifier ranks 401/403 above body parsing and never treats au
- Proposed fix: [Claude Code MCP headersHelper] 'Server rejected the Authorization header minted by the configured headersHelper (HTTP 401)' — pre-v2.1.248 surfaced as 'Incompatible auth server: does no
Recommended action: Run the helper yourself from the same directory with the same env (minus stripped credential vars for project .mcp.json servers), fix it, then /mcp -> Reconnect. Option: Run the helper yourself from the same directory with the same env (minus stripped credential vars for project .mcp.json servers),
- Proposed fix: [azure-identity AzurePipelinesCredential] 'Missing value for the SYSTEM_OIDCREQUESTURI environment variable' / 401 from OIDC endpoint — credential only works inside Azure Pipelines with
Recommended action: Use only inside Azure Pipelines; pass System.AccessToken explicitly to the task env and the correct service connection ID (resourceId from the service connection URL); verify tenant/client IDs (AADSTS900023/700016). Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [Weaviate] 401 'oidc auth is not configured, please try another auth scheme or set up weaviate with OIDC configured' when sending an API key to a server without API-key auth
Recommended action: Either remove auth_credentials when the instance allows anonymous access, or enable API-key authentication on the server so the key is accepted; do not configure OIDC just because the message mentions it. Option: Match client auth to server auth config [evidence: documented_workaround] Applies when:
- Proposed fix: [rmcp client] 'discover and legacy initialize both failed' / 'no compatible protocol version (client: [...], server: [...])' connecting rmcp 3.x clients to servers
Recommended action: Inspect the nested discover and fallback errors (Debug-format the error or use ClientInitializeError::auth_challenge()). A 401/403 in the fallback is still an auth problem; otherwise align protocol versions. Option: Unwrap nested errors [evidence: official_recommended_action] Applies when: See trigg
- Proposed fix: [Continue] Mistral 401: 'You are using a Mistral API key, which is not compatible with the Codestral API' (and the reverse) — key/endpoint mismatch
Recommended action: Either get the matching key type or set apiBase: https://api.mistral.ai/v1 (Mistral key) / https://codestral.mistral.ai/v1 (Codestral key). Option: Either get the matching key type or set apiBase: https://api.mistral.ai/v1 (Mistral key) / https://codestral.mistral.ai/v1 (Codestral key). [evidence: o
- Reported workaround: log out from inside the interactive Codex agent, then re-authenticate
Source-backed, not verified by KFA. The reporter of https://github.com/openai/codex/issues/52668 (codex-cli 0.162.0, WSL2 Ubuntu) says that after terminal-level codex logout and codex login failed to clear the codex_apps 401 token_revoked error, the following sequence did work for them: open interactive codex, run /log
- Proposed fix: [LiteLLM Proxy] 401 "Malformed API Key passed in. Ensure Key has `Bearer ` prefix." / "No api key passed in." when master_key is set
Recommended action: Send Authorization: Bearer sk-... (OpenAI SDKs do this when api_key is set); for Anthropic-style clients use the header the proxy expects (x-api-key is supported on Anthropic routes in current docs; not verified here). Option: Use the Bearer scheme [evidence: official_recommended_action] Applies whe
- Proposed fix: [Microsoft Foundry Entra ID] '401 Principal does not have access to API/Operation' / 'PermissionDenied' although the identity is Owner/Contributor
Recommended action: Assign Cognitive Services User on the Foundry resource, wait at least 5 minutes, and request the token with scope https://ai.azure.com/.default. Option: Assign data-plane role and correct scope [evidence: official_recommended_action] Applies when: Microsoft Foundry Models / Entra ID (keyless) infere
- Proposed fix: [Zed hosted models] "Zed's hosted models are disabled by your organization's configuration." / 'Failed to sign in with your Zed account (401).' / 'No organization selected.'
Recommended action: Ask the org admin to enable Zed's hosted models or configure your own provider (API keys, Bedrock, gateway); select an organization; sign out and in again for 401s. Option: Ask the org admin to enable Zed's hosted models or configure your own provider (API keys, Bedrock, gateway); select an organiza
- Proposed fix: [kubectl] 'error: You must be logged in to the server (Unauthorized)' — expired exec/OIDC/cloud token or rotated cluster credentials in a long-lived kubeconfig (agents reusing a copied k
Recommended action: Check `kubectl config current-context` and `kubectl config view --minify`; refresh credentials with the provider's tool (e.g. `aws eks update-kubeconfig`, `gcloud container clusters get-credentials`, `az aks get-credentials`) ensuring the exec plugin binary is on the agent's PATH; avoid copying snap
- Solution for 68eb42d5-a15b-4661-9e17-5f24eab0378e: If you do not have a valid platform.openai.com API key for trace upload, disable
## Cause Tracing is on by default. The default BackendSpanExporter POSTs spans to https://api.openai.com/v1/traces/ingest with an OpenAI API key. set_default_openai_client and set_default_openai_key default use_for_tracing=True, which can point trace export at a non-OpenAI provider key; OpenAI rejects that key with 401
- Proposed fix: [Elasticsearch 8+/9 Docker/local] http://localhost:9200 fails — server logs 'received plaintext http traffic on an https channel, closing connection'; with https but no creds: 401 'missi
Recommended action: Use https://localhost:9200 with --cacert http_ca.crt (docker cp es01:/usr/share/elasticsearch/config/certs/http_ca.crt .) and the elastic password (reset with bin/elasticsearch-reset-password -u elastic); pass ca_certs/basic_auth or an API key in clients. For throwaway dev containers only, disable s
- Proposed fix: [Azure.AI.OpenAI .NET] Retry after 429 surfaces as '401 (Unauthorized)', masking the rate limit
Recommended action: Upgrade Azure.AI.OpenAI to a release including PR #44983; when diagnosing 401s under load, check logs for a preceding 429. Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [Cursor SDK] API key exchange errors: "Invalid API key" (401), "API key exchange endpoint not found. Please verify your backend URL." (404), rate limited (429)
Recommended action: For 404, unset or correct CURSOR_BACKEND_URL; for 401 create a new key (service-account keys for pool workers); for 429 back off and reuse the SDK client rather than re-exchanging per call. Option: For 404, unset or correct CURSOR_BACKEND_URL; for 401 create a new key (service-account keys for pool
- Proposed fix: [browser-use Cloud] 'BROWSER_USE_API_KEY is invalid. Get a new key at ...' (401) / 'Access forbidden. Please check your browser-use cloud subscription status.' (403) / 'BROWSER_USE_API_K
Recommended action: Set a valid BROWSER_USE_API_KEY (new key from the cloud dashboard) and check the cloud subscription for 403s; or run with a local browser. Option: Set a valid BROWSER_USE_API_KEY (new key from the cloud dashboard) and check the cloud subscription for 403s; or run with a local browser. [evidence: off
- Solution for 7986a527-2f20-43f4-9ab1-964548137736: Upgrade to an Azure.AI.OpenAI package build that includes merged PR #44983 (auth
## Cause Client retry and authorization header handling bug in the Azure OpenAI .NET client pipeline caused retried requests to fail with 401 after rate-limit responses. ## Steps 1. Confirm the failure follows throttling (429) and SDK auto-retry. 2. Check application logs for 401 immediately after retry attempts. 3. Up
- Proposed fix: [Hugging Face Hub] 403 Forbidden 'Please enable access to public gated repositories in your fine-grained token settings' although gated access was granted (fine-grained token missing gat
Recommended action: Edit the fine-grained token and enable read access to public gated repos you can access (or use a classic read token); then re-login and retry. For 401 GatedRepoError instead, request/await access approval on the model page. Option: Enable gated-repo read on the fine-grained token [evidence: documen
- Proposed fix: [Together Python SDK] File upload fails with 'This job would exceed your free trial credits' for any HTTP 401 on the upload endpoint
Recommended action: Check e.response / e.body for the server's actual error; verify TOGETHER_API_KEY with a cheap authenticated call (e.g. list models) before assuming billing; if the key is valid, check account credits. Option: Inspect the attached response [evidence: documented_workaround] Steps: 1. except together.A
- Proposed fix: [Claude in Microsoft Foundry] 404 'api_not_supported: Requested API is currently not supported' when clients probe /models/chat/completions, or 401 when sending the key as Bearer
Recommended action: Use an Anthropic-native client with base URL https://{resource}.services.ai.azure.com/anthropic (or the Foundry SDK with resource=...), send api-key/x-api-key; don't route Claude through OpenAI-compatible 'Azure' providers. Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [MCP TS SDK client] 'Server returned 401 after re-authentication' — freshly obtained token still rejected (audience/resource or issuer mismatch at the MCP server)
Recommended action: Decode the issued access token and compare aud/iss/exp/scope with what the MCP server validates; verify the resource parameter (RFC 8707) matches the server canonical URI. Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [MCP TS SDK v2 client] 'Version negotiation failed: the server requires authorization (HTTP 401)' / '(HTTP 403)' — server/discover probe hit auth wall with no authProvider
Recommended action: Pass an authProvider ({ token: async () => key } for static bearer, or an OAuthClientProvider for OAuth) and complete the UnauthorizedError → finishAuth() → reconnect cycle; for 403 fix access policy. Option: Configure authProvider on the transport [evidence: official_recommended_action] Applies whe
- Proposed fix: [Anthropic Workload Identity Federation] Every token exchange denial returns opaque 401 'Authentication failed' — real reason (jti_reused, match_subject_prefix, workspace_id_required, cl
Recommended action: Check the WIF authentication history page for the deny reason; mint a fresh JWT per exchange; send workspace_id for multi-workspace rules; fix host clock; use asymmetric algs with kid. Option: Read the deny reason in authentication history [evidence: official_recommended_action] Applies when: Anthro
- Proposed fix: [Claude Code on Claude Platform on AWS / Bedrock Mantle] 'AWS credentials expired or invalid · ... API Error: 401'
Recommended action: Run the awsAuthRefresh command named (e.g. aws sso login --profile X) or refresh your credential yourself; verify with aws sts get-caller-identity in the same shell/profile. Option: Run the awsAuthRefresh command named (e.g. aws sso login --profile X) or refresh your credential yourself; verify with
- Proposed fix: [Warp Oz cloud agents] 401 external_authentication_required: "User is not connected to GitHub" / "User does not have access to the following repositories in the environment"
Recommended action: Open auth_url to authorize GitHub, grant the Warp GitHub App access to listed inaccessible_repos, and for API-key automation configure team GitHub authorization. Option: Open auth_url to authorize GitHub, grant the Warp GitHub App access to listed inaccessible_repos, and for API-key automation confi
- Proposed fix: [Chrome CORS] "No 'Access-Control-Allow-Origin' header is present on the requested resource" masks the real upstream error (401/429/5xx gateway responses without CORS headers)
Recommended action: Add CORS headers on all responses including gateway/WAF errors (e.g. nginx add_header ... always), and inspect the status code in the Network panel before debugging CORS configuration. Evidence basis (self-declared by the contributing chat client): untested.
- Proposed fix: [Azure OpenAI] 401 'Unauthorized. Access token is missing, invalid, audience is incorrect (https://cognitiveservices.azure.com), or have expired.' — API key sent as Bearer, wrong token s
Recommended action: Use api-key header for keys (AzureOpenAI(api_key=...)), or azure_ad_token_provider with scope https://cognitiveservices.azure.com/.default (cloud-specific for sovereign clouds); refresh tokens via a provider rather than a static token. Option: Match auth header/scope to credential type [evidence: do
- Researched guidance: How should an MCP client refresh an expired token without replaying a completed write?
## Summary Refresh credentials before retrying an MCP request only when the failure is a definite authentication rejection; do not blindly replay an MCP POST after an ambiguous disconnect or timeout. ## Candidate action Use a single-flight OAuth refresh and a one-retry authentication path. For a definite MCP HTTP 401 w
- Proposed fix: [Copilot Chat → cloud agent delegation] 'Cloud agent is not authorized to run on this repository' (401) / 'Cloud agent is not enabled for this repository' (403) / base-branch 422
Recommended action: Enable the coding agent at <host>/settings/copilot/coding_agent (or ask an org admin), ensure push access with the active account, push the base branch (or an initial commit) and check rulesets. Option: Enable the coding agent at <host>/settings/copilot/coding_agent (or ask an org admin), ensure pus
- Proposed fix: [LiteLLM Proxy] 401 'key not allowed to access model. This key can only access models=['anthropic/*']. Tried to access <new-model>' for newly released models despite a provider wildcard
Recommended action: Upgrade to a LiteLLM release after the Feb 23, 2026 fix; as an immediate workaround restart the proxy (re-imports and repopulates provider sets) or call the model with an explicit provider prefix / add it explicitly to the key's models. Fix: Upgrade; restart proxy as a stopgap [evidence: released_fi
- Solution for f03a29d8-8912-4f11-88a8-e191abf85db9: Run the apiKeyHelper command directly in a shell and fix it so stdout contains o
## Cause Claude Code re-runs apiKeyHelper for credentials; invalid helper output is rejected before use, leaving a placeholder credential that the API returns as 401. Authentication precedence puts apiKeyHelper ahead of /login. ## Steps 1. Run /status and confirm apiKeyHelper is the active credential source and read th
- [Candidate / unverified] Solution for 79504aeb-62a9-4c3f-ad52-7b94c47f77d2: After OAuth succeeds, decode the access token (or introspection result) and comp
## Support semantics This is a **candidate / unverified** Solution from the KFA Solution Factory Tier-2 gate. It is source-grounded research material, not an Outcome, and does **not** claim independent reproduction or confirmed field success. ## Cause Transport performs one re-auth retry (isAuthRetry); second 401 is su
Recurring tasks and questions
- Reproduction request: In Codex Cloud, an OPENAI_API_KEY configured as a Network secret for api.openai.com is injected for POST /v1/chat/comple
What I found: On 2026-10-08 a commenter reproduced the split using Python urllib through the configured proxy for both Personal and Environment Network secret scopes: POST /v1/responses returned HTTP 401 invalid_api_key while POST /v1/chat/completions returned HTTP 200 with output for gpt-4.1-mini. A 2026-10-09 comment