Pi Agent 保存多个 Codex 账号的 OAuth Token 安全吗？

Pi Agent 保存多个 Codex 账号的 OAuth Token 并非绝对安全。@narumitw/pi-accounts 会用私有权限和原子写入保护本地凭据文件，切换失败时也会停止当前提供商请求，但 Token 仍以可被当前用户进程读取的形式保存在磁盘上；恶意扩展、提示词注入后的命令、设备失窃或错误备份都可能造成泄露。

扩展保存的究竟是什么

OAuth 是开放授权协议。用户完成 Codex 登录后，客户端会获得代表账号访问权限的凭据，通常包括短期访问令牌和可用于更新它的刷新令牌。多账号扩展需要保留每个账号的凭据，才能在不重复浏览器登录的情况下切换。

这意味着账号标签不是简单的用户名列表。凭据文件中的内容可能足以让程序代表对应账号请求服务，刷新令牌的价值尤其接近长期密码。文件即使没有显示用户密码，也必须按高敏感密钥处理。

当前扩展怎样保存多个账号

@narumitw/pi-accounts 默认把命名账号写入：

~/.pi/agent/pi-accounts.json

如果设置了 Pi 的自定义 Agent 目录，文件会改为该目录下的 pi-accounts.json。数据按提供商分别保存账号映射和当前活动名称，除了 OpenAI Codex，还可管理其他受支持提供商的订阅 OAuth 账号。

第一次修改账号时才会创建文件。扩展会使用私有文件权限、校验存储结构，并以原子方式安装新文件，减少写到一半导致损坏的概率。

0600 权限保护了什么

在类 Unix 系统中，0600 表示文件所有者可读写，其他用户默认不能访问。这可以防止同一台机器上的普通低权限账号直接打开 Token 文件。

但以下对象通常仍能读取：

• 以当前用户身份运行的 Pi、扩展和 Shell 命令。
• 获得当前用户权限的恶意软件。
• 拥有更高系统权限的管理员进程。
• 被授权读取用户目录的备份、同步或安全软件。
• 解锁设备后能够操作该用户会话的人。

因此，0600 是必要的访问控制，不是加密。它不能阻止同一用户权限边界内的代码窃取令牌。

原子写入解决的不是泄露问题

原子写入通常先生成完整临时内容，再一次性替换目标文件。这样可以避免进程崩溃或磁盘异常留下半截 JSON，也能让多个操作更容易保持一致。

它主要保护完整性，不保护机密性。攻击者只要能够读取最终文件，仍能取得其中的凭据。不要把“原子存储”理解为“加密存储”。

切换失败时会发生什么

该扩展通过提供商自己的 OAuth 刷新实现更新选中账号，再把得到的认证信息应用到 Pi 运行时。它会验证实际运行时认证状态，验证成功后才报告切换完成。

如果刷新、凭据转换、运行时覆盖或验证失败，扩展会为受影响的提供商安装一个不含秘密但必然失败的运行时凭据，并中止该提供商的请求。它不会悄悄回退到默认账号、环境变量 API 密钥或另一个命名账号。

这种失败关闭设计可以降低切错账号和意外计费风险，但无法防止存储文件被其他本地进程读取。

主要泄露路径有哪些

风险来源	可能后果	控制方法
不可信 Pi 扩展	直接读取并上传凭据文件	审查源码，只安装必要扩展
仓库提示词注入	诱导 Agent 执行读取或外传命令	隔离项目，限制网络和挂载
云盘或备份	Token 被复制到更多设备或服务	排除目录并启用加密备份
宽松文件权限	同机其他账号读取	检查并修复权限
设备丢失	解锁后直接使用多个账号	全盘加密、屏幕锁和远程擦除
日志与诊断包	凭据被错误打印或打包	输出脱敏，提交前检查内容

为什么多个账号会放大影响

单一凭据文件集中保存多个账号，一次泄露可能同时影响个人、工作和组织账号。攻击者不需要逐个攻破登录流程，只需读取一个存储位置。

账号越多，误切身份的概率也越高。使用个人账号处理公司代码，可能违反组织的数据政策；用工作账号处理私人项目，则可能把内容纳入企业审计和保留范围。安全检查既要防止凭据被盗，也要防止正确凭据用在错误任务上。

如何检查本地文件权限

类 Unix 系统可执行：

ls -ld ~/.pi ~/.pi/agent
ls -l ~/.pi/agent/pi-accounts.json

账号文件预期只对当前用户开放读写。若权限异常，可在确认路径无误后修复：

chmod 700 ~/.pi ~/.pi/agent
chmod 600 ~/.pi/agent/pi-accounts.json

不要把命令直接套用到不确定的自定义目录。Windows 应查看文件的访问控制列表，确认没有向其他本地用户或宽泛用户组开放读取权限。

迁移旧账号文件要注意什么

当前扩展可以从旧的 pi-codex-accounts.json 迁移 Codex 凭据。迁移时会锁定和校验旧文件、修复为私有权限，再原子创建新的统一文件。

为了支持回滚，旧文件会被保留。这也意味着磁盘上可能同时存在两份敏感凭据。刷新令牌发生轮换后，旧副本可能已经失效，但不能据此假定它没有敏感信息。

确认新扩展稳定且不再需要回滚后，应先退出相关 Pi 会话并核对服务端授权状态，再安全处理旧文件。不要在扩展仍运行时随意修改或删除认证文件。

删除本地账号是否等于撤销 Token

不一定。扩展删除账号通常只是移除本地副本或恢复 Pi 默认登录，服务端已经签发的令牌可能仍在有效期内。真正的撤销需要通过账号安全设置、授权应用管理或提供商支持的退出机制完成。

怀疑泄露时，应按以下顺序处理：

1. 停止所有使用该凭据的 Pi 会话。
2. 在服务端撤销授权或退出相关会话。
3. 重新登录并生成新的凭据。
4. 清理本地账号文件中的旧快照。
5. 检查用量、活动记录和异常请求。

怎样更安全地使用多账号功能

1. 只从确认过的包名和仓库安装，核对版本与源码。
2. 不要同时加载会管理同一凭据的旧版和新版扩展。
3. 为个人与工作账号使用不同的操作系统账号或独立配置目录。
4. 开启全盘加密，使用强登录密码和自动锁屏。
5. 将 Pi 凭据目录排除在未加密云同步和普通诊断打包之外。
6. 不在保存主账号 Token 的环境中运行不可信仓库和扩展。
7. 切换后验证活动账号，不依赖本地标签名称猜测。
8. 定期删除不再使用的账号，并在服务端撤销旧授权。

处理不可信项目时如何隔离

Pi 没有内置沙箱。处理未知仓库时，应把 Pi 进程放进容器、虚拟机或系统级沙箱，并且不要挂载宿主机的 ~/.pi/agent。只把任务所需代码复制进去，使用独立、低权限、短期凭据，并在不需要联网时关闭网络。

仅把项目目录设为“不信任”不足以保护 OAuth Token。项目信任主要控制项目资源加载，不会限制 Agent 或扩展以当前用户权限读取凭据目录。

API 密钥是否一定更安全

不一定，但专用 API 密钥通常更容易划分项目、设置预算、轮换和撤销。当前多账号扩展只管理订阅 OAuth 账号，并不保存或切换 API 密钥配置。

自动化任务更适合使用单独 API 项目、最小权限密钥或秘密管理器，而不是复制个人订阅账号的刷新令牌。是否产生独立 API 费用，需要按提供商当前计费规则确认。

常见误区

文件权限是 0600 就不会泄露吗

不会。它只限制其他本地用户，当前用户权限下的程序仍能读取。

扩展通过 Pi 包页面展示就等于官方担保吗

不等于。Pi 包页面明确提醒第三方包可以执行代码并影响 Agent 行为，安装前仍需审查来源和实现。

恢复到 default 会删除保存的账号吗

不会。它只移除扩展对该提供商的运行时覆盖，恢复 Pi 原有认证；命名账号仍保存在扩展文件中。

扩展不自动轮换账号是否更安全

它可以降低绕过限额和意外切换的风险，但多个长期凭据集中保存的机密性风险仍然存在。

总结

Pi Agent 保存多个 Codex OAuth Token 的方案具备私有权限、原子写入、结构校验和失败关闭等保护，能减少文件损坏、误切账号和静默回退风险；但 Token 并未因此变成不可读取的秘密。只要当前用户权限下的恶意代码能够访问凭据文件，多个账号就可能同时暴露。安全使用需要结合全盘加密、隔离配置目录、可信扩展、最小权限环境、服务端撤销和定期账号清理。