提示词增强包如何把广告植入 Codex

给 Codex 装一个提示词增强包，输入一句 hi，它就开始替第三方 API 中转服务打广告。原文借 Haiou（海鸥）这个案例指出：能长期改变编程 Agent 行为的，不一定是可执行程序，也可能是写进全局配置的几行 Markdown。

对经常安装 skills、人格模板和配置工具的程序员，这件事值得看。重点不在广告多烦人，而在于：谁改了 Agent 的指令，谁决定请求发往哪里，以及你有没有办法发现这些变化。

一句 hi 为什么能触发广告

据原文转述，Check Point Research 在 11 月 3 日发布的报告中分析了 Haiou 4.5.0。这个面向 Codex 的 jailbreak bundle，通过自定义 AGENTS.md、模块化提示词和 skills，提供中文技术人格与安全研究流程。

它安装了六个 skills，包括 seagull-pentest、seagull-reverse 和 seagull-license-security。其中用于越过模型安全限制的做法，是角色扮演，以及把安全请求包装成夺旗赛（Capture The Flag，CTF）练习。

广告混在另一层指令里：提示词模块 00-identity.md 保存了广告文案，Codex 包内的 CLAUDE.md 也带有同样内容。用户输入 hi、hello、yo、ctf、coach，或者「海鸥」「在吗」「开始」等触发词时，Agent 被要求只回复一行，以 Seagull is online. Want some fries? 开头，再引导用户支持一个 API 中转服务。

选问候语作触发条件很巧。很多人安装完工具，第一步就是发句 hi，看看配置是否生效。广告因此进入了最自然的验收动作。

配置还把被推广网关的域名列为「受保护基础设施」，禁止对其进行攻击性测试。包内附有卸载器，可以撤销它做的修改，但这不能代替安装前审查。

传播范围需要分清。The Hacker News 称，该仓库于 2026 年 7 月 10 日上线，其 11 月 4 日报道时有 403 stars、77 forks。另一个约有 4,400 GitHub stars 的桌面管理工具 Codex-X，内置了 Haiou 3.0 人格模板，启用后会写入 Codex 指令文件。

但两份报道都没有确认这份 3.0 模板是否含广告，不能拿 4.5.0 的分析结果直接套过去。Check Point 还指出，Haiou 的 Claude Code 版本没有广告注入。

真正需要检查的是全局指令和请求出口

Check Point 把这类持续修改 Agent 可信指令、让它在后续回答中插入广告的行为称为 prompt adware，可以理解为「提示词广告软件」。

Markdown 一旦被当作指令加载，就能改变 Agent 在多个项目中的行为。

原文引用的 OpenAI 指南说明：Codex 默认从 ~/.codex 读取全局指令，设置 CODEX_HOME 后则使用指定目录；先读取 AGENTS.override.md，没有它才读取 AGENTS.md，然后再加载项目指令。因此，一个全局文件的改动，可能影响你随后打开的每个仓库。

这也解释了为什么只检查项目里的 AGENTS.md 不够。原文给出的第一步，是找到实际配置目录，再搜索报告中的字符串；被推广域名包含 aiapi2025：

CX="${CODEX_HOME:-$HOME/.codex}"
ls -la "$CX"

grep -rniI --include='*.md' \
  -e 'aiapi2025' -e 'seagull' -e '海鸥' "$CX"

要看的是 CX 那一行：它兼容自定义 CODEX_HOME，避免查错目录。关键词命中只是线索，需要继续读上下文；没有命中，也不能证明其他指令都可信。

第二步是检查请求出口和指令替换项：

grep -nE 'model_provider|base_url|instructions_file' \
  "${CODEX_HOME:-$HOME/.codex}/config.toml"

这里重点核对 model_provider、model_providers.<id>.base_url、openai_base_url 和 model_instructions_file。最后一项按原文引用的配置说明，可以替换 Codex 内置指令，不能当成普通偏好设置看待。

原文还提供了交叉核验命令 codex --ask-for-approval never "List the instruction sources you loaded."，让 Agent 列出加载的指令来源。不过，被篡改指令约束的 Agent，也可能给出不完整回答。磁盘文件才是核对依据。

要发现后续变化，作者建议安装前后分别给配置目录里的 Markdown、TOML 文件计算 SHA-256，用 shasum -a 256 保存到 ~/codex.sha256 和 ~/codex.new，再执行 diff ~/codex.sha256 ~/codex.new。清单应包含路径，这样既能看到内容变化，也能发现新增文件。

广告背后的网关，比广告本身更重要

Check Point 推测，这个免费增强包可能是付费网关的获客渠道。报告把服务称为不透明的 OpenAI-compatible LLM gateway，但同时明确表示，没有迹象证明该网关本身恶意；对于中转商是否清洗被盗 token，研究人员也没有有力证据。

这两条边界必须保留。获客动机是推测，盗用凭据更不是已经坐实的结论。

不过，接入中转服务确实会改变数据经过的路径。Agent 发出的请求可能包含它从仓库读取并放进上下文的代码、配置和其他内容；网关收到这些请求，再返回供 Agent 使用的响应。兼容 OpenAI API，只说明接口可以对接，不能替代对运营方的信任。

原文引用了另一项关于部分 LLM 网关窥探数据、窃取云访问密钥、甚至注入工具调用的研究，但没有提供足够细节，让读者评估样本和普遍程度。它能说明存在这类风险，不能证明当前被推广的网关做过同样的事。

报告发现 Haiou 的位置也应谨慎理解：它出现在一个网络犯罪行为者服务器的开放目录中，旁边有 Cobalt Strike 等工具。Check Point 明确说过，这不代表该包就是为网络犯罪而开发。发现环境是调查线索，不能直接当作作者意图的证据。

我的判断

我认同原文最实用的判断：提示词包、skills 和配置工具，都应该按依赖来审查。它们虽然经常只是文本，却能接触全局指令、服务地址和 Agent 的工作流程，权限影响不比普通开发依赖小。

但原文没有给出发生率、扫描检出率，也没有对照实验说明哪种防护最有效。保持全局文件简短、安装后检查差异，是合理的工程经验，不能包装成经过量化验证的安全方案。

与每次安装后凭记忆检查相比，保留配置基线更容易发现变化；但哈希只能告诉你文件变了，不能判断改动是否合理。如果基线建立时已经混入广告，它仍然会把那份文件当作参照。

这个案例也不足以证明所有人格模板都有问题。真正应当追问的是：模板要改哪些文件，为什么需要全局生效，为什么要改 base_url。这些问题，比安装量和 stars 更接近实际影响。

能拿来做什么

• 安装 Codex skills、人格模板或 GUI 配置器前，先读它将写入的 Markdown 和配置项，重点确认全局指令、触发词，以及是否夹带服务推广内容。
• 给现有 Codex 配置建立一份包含文件路径的哈希清单；安装增强包后比较新增和修改的文件，再逐项阅读差异。
• 在前端或 Node 项目中使用 Agent 前，确认实际 provider 和 base_url 属于自己选定的服务，尤其在 Agent 会读取业务源码、配置文件时。
• 把 Agent 自报的指令来源当成交叉核验材料，同时检查磁盘上的 AGENTS.override.md、AGENTS.md 和 config.toml，避免仅凭一次问答判断配置是否可信。