Claude Code 跑到一半时吊销泄露的 key：排空、换 key 与续跑

在长时间运行的编码会话中，如果发现当前使用的 API key 已经泄露，直接删除 key 可能导致正在进行中的请求失败，进而丢失尚未保存的上下文或代码修改。以下是一个按顺序执行的操作流程，旨在让轮换过程对当前工作影响最小。

第一步：评估泄露范围与当前会话状态

在动手之前，先确认两件事：

• key 的泄露途径与暴露程度：是本地配置文件被误提交、日志打印、还是其他渠道。这决定了轮换的紧迫性，但无论哪种情况，都应假定该 key 已不可信。
• 当前会话的进行状态：是否有正在等待响应的请求、已经生成了多少未保存的上下文、当前任务是否处于可中断的节点。

如果会话中有大量未保存的代码或对话上下文，优先保存工作副本（例如把当前对话导出或复制到本地文件），再进入下一步。

第二步：排空正在进行中的请求

排空的意思是让已经发出但尚未返回的请求自然完成，避免在切换 key 时中断它们。

• 停止发起新的请求：在客户端或脚本中暂停提交新任务。
• 等待当前请求返回：如果是流式响应，等待流结束；如果是普通请求，等待响应到达。
• 记录最后一个成功响应的位置：这可以是你已保存的对话历史、代码快照或任务清单。

注意：排空不是必须等待所有后台任务完成，而是确保正在进行的交互有一个明确的结束点。如果某个请求已经卡住，可以主动终止它，但要在终止前确认没有未保存的重要输出。

第三步：在聚合站轮换 key

由于聚合站使用统一的 API key 来调用多个模型，轮换通常只涉及一个 key 的替换：

• 在聚合站的控制台中，为泄露的 key 创建替代 key，或直接吊销旧 key 并生成新 key。
• 如果聚合站支持多个 key 并存，可以先生成新 key，验证可用后再吊销旧 key，以缩短服务中断时间。
• 更新本地配置：将客户端、环境变量或脚本中的 key 替换为新 key。
• 确认新 key 的权限与额度正常：发送一个简单的测试请求，验证鉴权通过。

第四步：安全续跑会话

切换 key 后，恢复会话时需要注意上下文的一致性：

• 如果会话历史保存在本地（例如对话记录、代码文件），直接使用新 key 继续即可，模型不会感知 key 的变化。
• 如果会话依赖服务端的会话状态，确认聚合站是否支持跨 key 的会话延续；若不支持，需要从最近保存的上下文重新建立会话。
• 续跑前，先发送一个轻量请求验证新 key 工作正常，再继续原来的编码任务。

常见注意事项

• 不要直接删除旧 key 而不准备新 key：这可能导致在生成新 key 之前无法继续工作，尤其是在需要立即续跑的场景。
• 不要忽略本地缓存或日志中的旧 key：轮换后，检查配置文件、环境变量、脚本和日志，确保旧 key 没有残留。
• 如果泄露的 key 曾被用于其他服务：评估是否需要同步轮换其他地方的凭据，但这不是本文的重点。
• 排空阶段的时间窗口：如果泄露风险很高，可以缩短排空时间，优先吊销 key，但要在吊销前尽可能保存当前会话的输出。

总结

在编码会话中轮换泄露的 key，核心顺序是：先保存工作副本、再排空进行中的请求、然后生成并切换新 key、最后验证并续跑。这个流程不依赖具体模型或客户端，适用于任何通过聚合站使用多个模型的场景。关键是把“吊销”放在“排空”之后，避免因鉴权失败而丢失正在进行的工作。