# 凭据

## 文档和凭据不是一类

文档可以靠"别去读"扛一阵。凭据不行：一个能读到 token 的进程，风险不在它读不读，而在**一旦读了无法追溯**——token 可以离机、可以等待、可以事后用。

## 现状（2026-11-08 实测）

同一个账号身份存在**两份独立副本，refresh 各自独立**：agent 侧的 auth 文件和 CLI 侧的 auth 文件。两份 JWT 指向同一个账号，跑着十个 CLI 进程。

后果：只撤销其中一份等于没撤，另一份照样续命。

## 凭据类型的差别

- **OAuth 登录态**：同一个身份、同一份额度、同一份归因。出事分不出是谁。
- **API key / 独立子账号**：能归因，能单独撤销。

所以换的不只是"不共享"，是**可归因和可撤回**这两件事。别把"换 key"本身当目的。

## 轮换顺序

1. 停 daemon（进程只在启动时读一次凭据文件，运行中改文件对已跑的进程无效）
2. provider 侧撤销该账号下**全部**会话
3. 换本地凭据，两份都清
4. 重启
5. 验证：旧 refresh 必须 `invalid_grant`、旧 access 必须 `401`。**验前先清本地缓存**，否则缓存会掩盖失效

## 残余窗口

撤销 refresh 不回收已签发的 access，后者活到 `exp`。实测 access 的 `exp - iat` 是整整十天。这段窗口按**已泄露**处置，不是已关闭。

## 断言要留档

一次全绿只等于那一次通过。要对两份副本、两类 token 各自都打一次失败调用，附时间和命令记下来。任一项缺失，结论只能写"部分验证"。