拿到 Key 后，先决定它保存在哪一层
AIGoCode API Key 可用于 API 调用、Claude Code、Codex 以及桌面客户端等接入场景。创建成功只是开始，接下来还需要把密钥放在合适的位置，并避免在分享项目或排错时一起公开。
本文解决的是本地开发的密钥存放与泄露处理顺序，不重复介绍每个客户端的分组与地址设置，也不会让你在文章中填写真实 Key。
创建后保存到本地安全位置
官方获取 API Key 页面给出的步骤是登录控制台、打开 API Key 页面、创建新 Key，复制后保存到本地安全位置，再在工具或代码中使用。
建议自己额外记录用途，比如“本地测试脚本”或“某个客户端”。用途记录与密钥值分开，有助于以后核对哪处配置需要更新；它是管理建议，不代表平台自动提供了本文未说明的密钥分类功能。
配置工具时，以工具教程要求的字段填写。不要把 Key 当成地址的一部分随意拼接，也不要为了让别人帮忙排错，就把完整配置原样贴出去。
Git 仓库与前端公开代码都不适合放真实 Key
官方明确要求不要把 API Key 提交到 Git 仓库，也不要放进前端公开代码。可以用两项检查来落实：提交前检查将要分享的配置和示例；做网页接入时检查真实密钥是否进入了浏览器可见代码。
把字符串换了一个变量名，不能代替存放位置检查。即便项目是自己使用，也应避免把真实值作为默认示例复制到后续文件。示例中使用占位符，真实值留在自己的受控环境。
这里不讨论具体框架的服务端接口实现，也不承诺某种变量前缀一定安全。判断重点是这份配置最终会被谁读取，是否随代码公开或分发。
本地开发优先使用环境变量
官方建议本地开发优先使用环境变量，并展示 AIGOCODE_API_KEY 的占位示例。实际项目中，先按所用程序的配置方式加载，再验证程序确实能取到该值。
环境变量的目的在于将真实配置与可分享代码分开，不是让你在日志里把变量值打印出来。排查时可以检查是否存在、配置来源是否正确，而不显示值本身。使用本地环境文件时，也要确认它没有被误提交或作为附件分享。
这些是操作建议；本文不替你改写现有程序或声明所有工具都会自动读取同名变量。客户端若有专属配置入口，仍按其当前文档操作。
发现泄露时，先处理旧 Key
官方给出的处理要求是发现 Key 泄露时，立即删除旧 Key 并创建新 Key。仅从当前代码里删掉字符串，不能等同于已完成这一步；应由你在控制台处理旧密钥，再更新实际使用它的工具或程序配置。
替换后可用自己原本的最小验证方式检查新配置，避免一次把模型、地址和协议也改掉。请自己保留哪些客户端已替换的记录，逐个核对。本文只说明处理顺序，没有替你删除、创建或使用任何密钥。
不要把新 Key 再发给同一条公开讨论，也不需要向协作者展示完整值来证明已换新。分享处理结果时说明“旧 Key 已处理、受影响配置已更新”即可。
第三方工具还需要核对分组
官方特别说明，在 Claude Code、Codex、Cherry Studio、OpenCode、OpenClaw 或 Hermes 等工具中使用时，应选择支持第三方调用的分组，否则可能出现工具鉴权通过但模型请求失败。
所以，“密钥存放正确”和“分组适合该客户端”是两项检查。存放问题处理后，若仍有接入错误，再按具体工具教程核对分组与地址；可以参考本站第三方工具 Key、协议和模型选择以及401 与 403 排查。
完成时检查四件事：真实值没有进入仓库，没有进入公开前端代码，本地配置来源明确，泄露旧 Key 已按官方步骤处理。它们分别对应公开范围、加载方式和异常处置，不能用一次“请求成功”替代。