夜雨聆风
我看完 codexui-android这事的第一反应是：
上次我们担心的是 Codex 进浏览器后拿到 Cookie；这次更直接，第三方外壳开始偷 Codex 自己的登录态。
这两天 The Hacker News 把这个事情推到了台前：一个看起来挺像样的 OpenAI Codex 远程 UI，被安全公司 Aikido 指出在过去一个月里偷偷读取用户本地的 Codex 登录文件，并把里面的 token 发到攻击者服务器。
所以这篇不是再讲一遍浏览器插件。
也不是那种低级 typosquat。
不是把 react拼成 reaact，骗几个人 npm install。
它更阴。
它是一个真实仓库、真实功能、真实用户在用的工具。Aikido 说它有大约 27,000 周下载量。开发者装它，不是因为手滑，而是因为它真的解决了一个痛点：想远程用 Codex，想在手机上用 Codex，想把 AI coding agent 从电脑搬到别的入口。
然后它在启动时读你的：
或者：
里面有什么？
access_token、refresh_token、id_token、account ID。
最要命的是 refresh_token。
这东西不是一次性门票。
它更像一把能不断换新门票的钥匙。
偷一次，长期冒充你。
这才是最恶心的地方。
过去我们讨论 AI coding agent 安全，总盯着“它会不会乱删库”“它会不会执行危险命令”“它会不会被 prompt injection 带跑”。
这些当然重要。
但这次事情提醒得更狠：
只要 AI 工具开始替你登录、替你访问仓库、替你跑 agent，攻击者最想偷的就不是代码，而是你已经登录好的身份。
别把它看成一个 npm 包翻车
很多人看到供应链攻击，会下意识把它归到“npm 又脏了”。
这话没错，但太浅了。
如果只是一个 npm 包恶意更新，安全团队有一套老办法：锁版本、看 lockfile、做 SCA、扫恶意域名、禁 postinstall、查 maintainer。
这些都该做。
但 codexui-android的危险不只在 npm。
Aikido 披露的链条是这样的：
一个名为 codexui-android的工具，自称是 OpenAI Codex 的远程 Web UI。
它的 GitHub 仓库看起来正常。
项目在持续开发。
功能也不是假的。
真正的恶意代码不在 GitHub 源码里，而在发布到 npm 的包里。
入口文件一启动，先 import 一个 chunk：
这个 chunk 在模块加载时直接执行。
不用用户点按钮。
不用跑某个隐藏命令。
不用等你打开某个页面。
它做三件事：
读取 Codex 本地 auth 文件。
用 anyclaw2026作为 XOR key 做一层简单混淆，再 base64。
POST 到：
域名还故意起成 sentry.*。
这不是随便起名。
开发者看到网络里有 sentry，第一反应往往是错误上报、遥测、崩溃日志。
尤其一个远程 UI 需要 telemetry，听起来也不奇怪。
攻击者知道你会这么想。
所以他把偷 token 的出站流量伪装成正常监控。
这就是这件事比普通恶意包更值得写的地方：
它不是靠粗糙伪装骗安装，它是把“可信工具”的每一层都做得像真的。
真实功能负责获客。
GitHub 源码负责洗白。
npm artifact 负责下毒。
Sentry 风格域名负责降低警觉。
Android App 负责扩大入口。
这已经不是“小黑客塞一段脚本”。
这是产品化的凭证收割。
为什么 Codex 的 token 值钱
很多人对 token 没感觉。
好像丢了一个 token，重新登录一下就完了。
不是。
要看是什么 token。
access_token通常寿命短一点，像临时通行证。
refresh_token不一样。
它的作用是换新的 access token。
一旦攻击者拿到 refresh token，只要服务端没有吊销，它就可以在你不知道的情况下持续刷新会话。
这意味着什么？
不是“黑客看了一眼你的 Codex 页面”。
而是他可能获得一个长期、安静、可重复使用的身份入口。
AI coding agent 的身份入口又非常敏感。
因为它往往绑定了这些东西：
✓ GitHub 仓库访问
✓ ChatGPT / Codex 账号能力
✓ 云端 agent session
✓ PR 创建权限
✓ issue / task 读取权限
✓ 私有代码上下文
✓ 可能还有企业 SSO 下游权限
过去偷开发者凭证，攻击者喜欢 SSH key、npm token、GitHub PAT、AWS key。
现在多了一类新猎物：
AI Agent Login Token。
这个东西更隐蔽。
因为它不是传统安全资产清单里最显眼的一项。
很多团队的 secret scanner 会扫 .env。
会扫 AWS_ACCESS_KEY_ID。
会扫 ghp_开头的 GitHub token。
但有多少团队把 ~/.codex/auth.json、~/.claude/、~/.cursor/、~/.config里的 agent 登录态纳入了资产管理？
少得可怜。
这就是攻击者舒服的地方。
他们不需要打穿你的模型。
不需要说服 AI 做坏事。
不需要破解 OpenAI。
他们只要等你装一个“更方便的 Codex UI”。
你登录。
本地写下 auth 文件。
它读取。
它上传。
结束。
真正被打穿的不是 Codex 的推理能力，而是开发者对周边生态的信任。
这个 Android 链条，更像一次供应链预演
更有意思的是 Android 部分。
Aikido 说，同一个作者还在 Google Play 上发布了一个叫 OpenClaw Codex Claude AI Agent的应用，包名是 gptos.intelligence.assistant。
这里先说清楚：
这个名字里带 OpenClaw，不等于它和我们平时说的 OpenClaw 项目有官方关系。
恰恰相反，这种把一堆热门词塞进名字里的产品，才是最该警惕的。
OpenClaw、Codex、Claude、AI Agent。
每个词都能蹭一点流量。
每个词都让用户觉得“这玩意儿可能挺先进”。
Aikido 披露的 Android 运行方式更骚。
APK 本体看起来不大，也不直接把恶意 npm 包完整塞进 APK。
它在首次运行时解压一个类似 Termux 的 Linux userland 到私有目录，然后通过 PRoot 跑 Node.js。
启动脚本类似：
看出问题了吗？
@latest。
版本不锁。
这意味着 Google Play 上架前扫到的 APK，和用户真正运行时拉下来的 npm 包，可以不是同一个安全状态。
这是移动端审查最讨厌的一类绕法：
商店审核看的是壳。
真正的执行体运行时再拉。
在传统 App 安全里，这叫动态载荷、远程代码、后门更新。
放到 AI coding 工具里，它就变成了：
一个看起来像移动 Codex 客户端的东西，实际上是一个会拉取 npm 远程载荷的凭证收集器。
这比单纯 npm 包更麻烦。
因为用户的心理防线不一样。
开发者装 npm 包时，多少还会想一想。
但手机上装一个“Codex 客户端”，很多人会把它当普通 App。
登录一下。
扫个码。
授权一下。
然后 auth.json 在 PRoot 里的运行环境生成。
npm 包读走。
上传。
用户可能完全没意识到，这不是“手机上用 AI 编程”，而是把自己的 AI 编程身份交给了第三方。
这件事和 SymJack 不一样，但指向同一个未来
昨天写 SymJack，核心问题是 approval prompt 在说谎。
用户看到的是普通文件复制，真实效果是 symlink 改写 agent 配置，下次启动恶意 MCP server。
今天这个不一样。
这里没有复杂 symlink。
没有 approval 绕过。
没有 prompt injection。
它更朴素，也更致命：
你主动把登录态交给了一个第三方外壳。
这其实更接近真实世界会大规模发生的事故。
为什么？
因为 AI 编程工具正在快速长出周边生态。
远程 UI。
移动端壳。
桌面托盘。
浏览器插件。
MCP marketplace。
一键部署模板。
团队协作面板。
日志分析器。
token 统计工具。
大家都在围绕 Claude Code、Codex、Cursor、Copilot 做“增强层”。
有些增强层很有价值。
但增强层天然有一个诱惑：
它离用户更近。
它离 token 也更近。
以前一个 VS Code 插件偷点东西，可能偷工作区文件、环境变量、Git 凭证。
现在一个 AI coding 外壳，可以偷的是 agent 登录态。
这玩意儿更像“代理你的开发者身份”。
你不是丢了一个工具账号。
你丢的是一个能代表你继续和 AI coding 后端交互的身份。
这就是我对这件事的核心判断：
AI coding 生态正在进入“外壳劫持”阶段。谁控制入口，谁就可能控制身份。
GitHub 源码干净，不代表 npm 包干净
这次还有一个非常适合拿来教育团队的点。
很多人审开源项目，只看 GitHub。
Star 数。
README。
Issue 活跃度。
提交历史。
作者头像。
看起来都不错，就装了。
但现代供应链攻击早就不只打源码仓库。
它打的是发布产物。
GitHub 上没有恶意代码。
npm 上有。
本地 npm install的是 npm artifact，不是你刚刚看过的 GitHub 页面。
Aikido 这次就是靠 published package 里的 sourcemap 把逻辑扒出来的。
这说明什么？
说明“开源”这两个字不再自动等于“可审计”。
你审的是仓库 A。
你运行的是产物 B。
中间经过 build、bundle、minify、publish、postpack、CI secret、npm account、maintainer 权限。
任何一个环节被污染，最后跑在你机器上的都不是你以为的那份代码。
在 AI agent 场景里，这个问题会被放大。
因为 AI 工具的周边包经常需要这些权限：
✓ 读本地配置目录
✓ 启动本地服务
✓ 打开浏览器回调
✓ 读写工作区文件
✓ 调用 CLI
✓ 和远端 API 交换 token
✓ 建立 WebSocket 或 HTTP tunnel
这些行为单独看都“合理”。
远程 UI 读配置，合理。
移动端壳跑本地 server，合理。
Sentry 上报错误，合理。
问题是攻击者就藏在“合理”里。
安全最难防的，从来不是一眼假的危险命令。
而是那些在产品语境里看起来完全说得通的权限。
你现在该怎么查
如果你用过 codexui-android，或者装过任何非官方 Codex 远程 UI、移动端壳、第三方客户端，我建议你不要先安慰自己。
先按已泄露处理。
第一件事，不是删 App。
是吊销和重登。
能在 OpenAI / Codex 相关后台退出所有会话就退出。
能重新登录就重新登录。
能换 API key 就换。
如果企业里用 SSO，把这类事件当成开发者身份异常处理，而不是当成“某个 npm 包有毒”。
第二件事，检查本机是否存在 Codex auth 文件。
这个命令只检查路径是否存在，不打印内容：
如果存在，不要把它复制给任何人，不要截图，不要贴到聊天窗口。
这不是普通配置。
这是身份材料。
第三件事，查你有没有装过可疑包。
如果团队机器上装过，别只卸载。
卸载只是停止未来执行，不等于过去没泄露。
第四件事，查项目依赖里有没有拉过相关包。
第五件事，把 AI 工具登录态列进你的安全资产表。
这句话看起来像废话，但放到生产环境里很要命。
你不能只管理 GitHub PAT，不管理 Codex token。
不能只管理 AWS key，不管理 Claude / Cursor / Codex 的本地会话。
不能只扫 .env，不看 agent 的配置目录。
因为攻击者已经证明：
他们知道这些文件在哪。
他们知道怎么读。
他们知道怎么伪装上传。
企业更该怕的，是“影子 AI 工具”
个人用户中招，损失已经很大。
但企业环境更麻烦。
因为企业里真正危险的不是官方工具本身，而是员工为了方便装的“影子 AI 工具”。
官方 Codex 不够好用？
装个远程 UI。
Claude Code 手机上不方便？
装个移动壳。
Cursor 没某个功能？
装个插件。
MCP server 不够？
从 GitHub 拉一个。
这些东西往往不走采购。
不进安全评审。
不在 MDM 白名单。
也不会被工程平台团队统一配置。
它们只存在于某个开发者的电脑或手机里。
但它们能拿到的身份，可能是企业级的。
这就是影子 AI 工具最危险的地方：
入口是个人效率，后果是组织凭证。
一个开发者为了周末在手机上看 Codex 任务，装了一个第三方 App。
它偷走 refresh token。
攻击者拿 token 继续访问。
如果这个 Codex 身份能看到私有仓库、issue、PR、云端任务，事情就不再是个人电脑安全问题。
它变成企业开发环境的侧门。
传统安全团队喜欢问：
“这个工具有没有管理员权限？”
Agent 时代要换一个问法：
“这个工具能不能拿到已经登录的 AI 开发者身份？”
如果能，它就是高危。
不管它 UI 做得多漂亮。
不管它 README 写得多真诚。
不管它是不是开源。
以后判断 AI 工具，先问四个问题
我建议所有团队以后看第三方 AI coding 工具，先别急着试功能。
先问四个问题。
第一，它会不会读取官方工具的本地登录态？
比如 ~/.codex/auth.json、系统 keychain、浏览器 profile、Claude / Cursor / Copilot 的配置目录。
如果会，默认高危。
第二，它的源码和发布产物能不能对应？
GitHub 干净没用。
你要知道 npm 包、VS Code 插件、APK、桌面安装包里实际跑的代码是什么。
最好能做到 reproducible build。
做不到，至少要锁版本、校验 hash、限制来源。
第三，它有没有运行时拉取代码？
尤其是这种：
@latest在服务器上跑已经够危险。
在一个会处理 AI 登录态的移动 App 里跑，更离谱。
第四，它的出站网络能不能解释清楚？
别看到 sentry就默认安全。
别看到 telemetry就放行。
任何会读取 token 的工具，都应该有可审计的 egress 策略。
发到哪里。
发什么。
为什么发。
能不能关闭。
有没有日志。
讲不清楚，就不要装。
对 OpenClaw 这类工具的提醒
这件事里出现了 “OpenClaw Codex Claude AI Agent” 这个名字，所以我反而想多说一句。
未来开源 AI 工具一定会遇到品牌滥用。
越有用户，越有人蹭名字。
OpenClaw、Claude、Codex、Cursor 这种词，会被拼进各种 App、npm 包、Chrome 插件、MCP server 名称里。
普通用户分不清。
他们看到熟悉名字，就会降低警惕。
所以真正成熟的 AI 工程项目，不能只写代码。
还要经营信任边界。
官方发布渠道要清楚。
插件签名要清楚。
包名命名空间要清楚。
安装命令要清楚。
哪些是官方，哪些是社区，哪些是未知第三方，要让用户一眼能看懂。
否则攻击者会替你做生态。
然后把用户带到沟里。
这不是品牌洁癖。
这是安全问题。
Agent 时代，名字本身就是攻击面。
我的判断
codexui-android这事，不是一个孤立恶意包。
它是 AI coding 工具生态成熟之后必然出现的一类攻击：
第三方外壳通过提供便利，换取用户登录，再把长期身份偷走。
这比“模型会不会犯错”现实得多。
模型犯错，你还能看 diff。
Agent 乱跑命令，你还能拦 approval。
但登录态被偷，很多时候你连事故发生的瞬间都看不到。
它没有炫技。
没有复杂漏洞链。
没有绕过内核。
它只是利用了一个非常人性的东西：
开发者为了省事，会安装更方便的工具。
而更方便的工具，往往离你的身份最近。
所以以后别再只问：
“这个 AI 工具好不好用？”
先问：
“它有没有资格碰我的登录态？”
如果答案说不清楚，就别装。
因为在 AI Agent 时代，最贵的不是代码。
是那个能替你继续工作的身份。
