[BUG] First-run API key approval dialog defaults to "No"; a held Enter silently rejects the key with no recovery guidance

Open 💬 0 comments Opened Jul 6, 2026 by cjpeterein

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When a user configures an API key (via settings.json env/apiKeyHelper or environment) and starts Claude Code for the first time, a dialog asks whether to use that key. The dialog defaults to No.

Two problems follow from that default:

  1. A user pressing Enter to advance through the first-run prompts (theme selection, trust dialog, etc.) accepts the default and silently rejects their own key. The key's substring is recorded in the customApiKeyResponses.rejected list in ~/.claude.json.
  2. From then on, every launch fails with Not logged in * Please run /login, even though the configuration is valid. The only recovery is hand-editing ~/.claude.json to remove the key substring from customApiKeyResponses.rejected and restarting so the prompt reappears — and there is ZERO indication to the user that this is the correct course of action: not in the error message, not in /login, not in claude doctor.

The "No (recommended)" label makes this worse: Claude Code cannot know whether the key was set deliberately (enterprise provisioning, gateway deployment) or leaked into the environment by accident, so recommending rejection is a guess presented as guidance. Users who provisioned the key on purpose are steered toward breaking their own setup.

This is a recurring onboarding failure in our enterprise deployment (LiteLLM gateway with per-user keys configured via settings.json). Users who mis-answer the prompt appear "broken", cannot self-diagnose, and represent a significant support burden.

What Should Happen?

  1. The API key approval dialog should require an explicit selection. The default should be "no action": stay at the prompt until the user deliberately chooses Yes or No, so holding or repeatedly pressing Enter cannot answer it by accident. Neither option should be labeled "(recommended)" — Claude Code has no way to know whether the key is intentional, so it should present the choice neutrally (it can still explain the security consideration in the prompt text).
  2. claude doctor should detect the condition where the key Claude Code would actually use — from settings.json, the environment (ANTHROPIC_API_KEY/ANTHROPIC_AUTH_TOKEN), or the output of a configured apiKeyHelper — matches an entry in customApiKeyResponses.rejected, warn about it, and explain how to clear it (or offer to clear it). The apiKeyHelper case matters because the rejected key never appears in any config file: doctor has to invoke the helper to notice the collision.
  3. The Not logged in * Please run /login error should also mention when a configured key was previously rejected.

Error Messages/Logs

Not logged in * Please run /login

Steps to Reproduce

  1. Configure a valid API key for a fresh user, e.g. in ~/.claude/settings.json:

``json
{
"env": {
"ANTHROPIC_BASE_URL": "https://<gateway-host>",
"ANTHROPIC_AUTH_TOKEN": "<valid key>"
}
}
`
(Reproduces the same way with
ANTHROPIC_API_KEY`.)

  1. Ensure no prior state: no ~/.claude.json, not logged in.
  2. Run claude. At the "Do you want to use this API key?" dialog, press Enter (accepting the default), or explicitly select No.
  3. Claude Code exits the auth flow. Every subsequent launch shows Not logged in * Please run /login.
  4. Run claude doctor: no warning about the rejected key.
  5. Inspect ~/.claude.json: the key substring appears under customApiKeyResponses.rejected.
  6. Workaround: remove the substring from the rejected array, restart claude, answer Yes when re-prompted.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.201 (Claude Code)

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

  • OS- and shell-independent: reproduced on macOS/Terminal.app, but the behavior lives in the first-run auth flow, not the platform layer; also observed on Windows and Linux.
  • Platform "Other" = Anthropic-compatible enterprise LiteLLM gateway via ANTHROPIC_BASE_URL; also applies to the Anthropic API directly.
  • The dialog reads: Detected a custom API key in your environment / Do you want to use this API key? / 1. Yes / > 2. No (recommended) / Enter to confirm · Esc to cancel. Labeling the rejecting option both as the default and as "recommended" compounds the problem for users whose key was intentionally provisioned.
  • ~/.claude.json stores only a substring of the key in customApiKeyResponses, so the rejected entry is not obviously connected to the configured key when a user inspects the file or searches for their full key.
  • Enterprise onboarding docs currently have to document the hand-edit workaround; a safer default plus a claude doctor check would remove that class of support tickets.
  • Related (searched, none cover this ask):
  • #21771 (closed, not planned) — feature request to skip the dialog entirely for pre-provisioned keys; includes a screenshot of the dialog and a customApiKeyResponses.approved pre-seeding workaround. This report asks the opposite: keep the dialog but make it require explicit selection, and make claude doctor detect a rejected configured key.
  • #4714 (closed) — onboarding ignores environment settings.
  • #9699 (closed) — prompts for authentication despite ANTHROPIC_API_KEY set.
  • #37620 (closed) — hotkey mapping caused accidental "no" answers on yes/no prompts; same accidental-rejection failure mode, different input path.

View original on GitHub ↗