怎么突然要重新登录？残留 key 的干扰

AI 编程工具用得好好的，Claude Code 突然要求重新登录，或者甩出一句 Authentication failed；更蹊跷的是有人登录状态明明正常，API 账单却在悄悄上涨。遇到这类怪事，第一嫌疑人往往不是账号本身，而是环境变量里一把残留的 ANTHROPIC_API_KEY——它挂在 shell 里，会在你不知情时把请求从订阅道接走，改成 API 按量计费。这个坑在 Codex 那边有一模一样的版本，社区求助帖常年不断，见Codex 静默切 API 计费一篇；这篇按 Claude Code 的口径给出排查顺序：先分流、再查变量、再清源头。

先定位：请求到底走了哪条道

Claude Code 的认证有两条道：订阅账号授权，用量记进订阅额度；API key，按量计费单独出账。两条道并存时，环境变量里的 ANTHROPIC_API_KEY 优先级很高：只要它在 shell 环境里挂着值，CLI 就拿它当凭据，订阅额度一动不动。判断当前走哪条道，用 /status：显示的认证方式与你的预期不符，就是改道实锤；显示正常但行为仍怪，再往下查。定位先行，别一上来就折腾账号密码——两条道的账本完全不同，见AI API一篇的计费基础。

第一查：ANTHROPIC_API_KEY 是否残留

终端里 echo "$ANTHROPIC_API_KEY"，有输出就是残留。这把钥匙的来历通常有三种：早前照着教程配过一次 API key，后来改用订阅，变量忘了清；装其他开发工具时脚本顺手写入；从旧机器迁移环境配置时原样带过来。它平时安静无害，与订阅并存时才开始作祟——你以为在花订阅额度，账实际记在 API 上。查完当前会话，还要多想一层：这个值多半不是凭空冒出来的，源头藏在某个配置文件里。

第二查：登录态本身是否完好

变量查完没问题，或者清完变量仍报错，再查登录态。/status 看账号与认证方式，若显示未登录或凭据异常，走标准连招：claude 重新走一遍授权流程，详见登录流程一篇。顺序很重要——先清变量再重登，否则新登录又可能被旧变量压住，绕一圈回到原地。两次动作之间重开一个终端会话，保证环境干净。

清理动作：unset 与源头一起清

清理分两层。当前会话用 unset ANTHROPIC_API_KEY，立刻生效，但只治标：这个变量多半写在 shell 配置文件里（.bashrc、.zshrc 之类），下个会话又会回来。治本要打开配置文件，把写变量的那一行删掉或注释，再重开终端验证 echo 无输出。清完跑 /status 复核认证方式回到订阅，再让 Claude Code 干一件小活确认正常。想核对得细一点，可以让 DeepSeek 列出你所用 shell 会加载的全部配置文件路径，逐个检索变量名；豆包和 Kimi 则适合解释为什么环境变量会跨会话存活，弄懂机制后排查就不再靠背步骤。

预防：把查变量变成固定动作

这个坑的复发率很高，预防靠三个固定动作：换机器、装新工具、迁移环境之后，都重查一遍 ANTHROPIC_API_KEY 与 /status；团队协作的机器，新成员接手环境时把环境变量列为必查项；需要 API key 的场景，按会话临时注入，用完即撤，不写进长期配置。两条认证道的切换本来就合法合规，问题从来不在并存，而在不清不楚——把「当前到底走哪条道」变成随时能答的问题，账单与心理预期就不会再分家。档位与认证选择的背景，另见档位与解法一篇。

残留 key 排查速查

• 异常表现：突然要求重新登录、Authentication failed、API 账单在涨
• /status 先分流：认证方式与预期不符即改道
• echo 查 ANTHROPIC_API_KEY，有值先 unset
• shell 配置文件里的源头一并清，重开终端验证
• 换机器、装新工具后重查，团队接手必查

关于残留 key 的三问三答

• 为什么它比订阅登录优先？：环境变量是显式指定的凭据，CLI 把它当作明确意图优先采用；这与 Codex 处理 OPENAI_API_KEY 的逻辑同源，两个工具的坑可以互相印证。
• unset 之后下个会话又回来了？：说明源头还在 shell 配置文件里，按会话 unset 只清当前；找到写变量的那一行删掉，才算清干净。
• 平时不用 API key 要留着这把钥匙吗？：不用。留着只有风险没有好处：要么静默改道烧 API 账单，要么与订阅凭据打架引发认证失败。需要时按会话临时注入更稳。