AI 编码客户端正在互相读取彼此的个人指令

受控测试发现，Muse Code、GitHub Copilot CLI、OpenCode 和 Grok 在默认远程请求中发送了为竞争性 AI 客户端编写的个人规则。Claude、Gemini 和 Kimi 选择了更窄的边界，这与“自动跨客户端加载是行业标准”的说法相矛盾。Cursor 打包的代码则将这一担忧扩展到了技能层面。

By · Published · Updated

RUNTIMEWIRE INVESTIGATION — Original analysis

Original reporting by RuntimeWire, based on documents, testing, data analysis.

Why it matters

Coding agents are turning home-directory configuration into portable prompt context. Without approval before transfer, switching tools can expose instructions beyond the workspace a developer selected.

Reporting record

Finding

Controlled tests found Muse Code, GitHub Copilot CLI, OpenCode and Grok sending personal rules written for competing AI clients with default remote requests.

How we verified

Methods: documents, testing, data analysis.

Reproduction

Reproduction does not apply to this reporting (document-driven).

Company response

RuntimeWire requested comment; the company had not responded by publication time.

Illustration of personal configuration files being exchanged between competing coding clients such as Muse Code, GitHub Copilot CLI, OpenCode and Grok, with Claude, Gemini and Kimi nearby.

GitHub Copilot CLI 不应该知道哪个果园已被批准。

RuntimeWire 已将答案 —— COPILOT-CLAUDE-ORCHARD-5186 —— 放在测试用户主目录下的 ~/.claude/CLAUDE.md，即 Claude Code 的个人指令文件中。所选工作区是空的。基准运行返回了 None。

在下一次默认运行中，Copilot 加载了 Claude 文件，在第一个远程提示中包含了其指令并精确返回了被植入的字符串。当 RuntimeWire 使用 Copilot 的 --no-custom-instructions 开关重复该提示时，该文件被排除，答案又回到 None。非交互式默认运行在传输前没有显示任何通知。

这一结果延续了 RuntimeWire 在 8 月 9 日对 Meta 的 Muse Code 的调查。该报道显示 Muse 默认在其第一次请求中放入完整的个人 Codex 和 Claude 指令。这促使我们将测试范围扩大到其他编码代理。

扩展审查产生了另外三个实时结果。GitHub Copilot CLI、OpenCode 和 Grok 在其默认设置下都使用了测试中的 Claude 个人指令。Cursor Agent 的打包 JavaScript 会标识个人 Claude 和 Codex 技能目录，在启用第三方可扩展性时递归查找 SKILL.md 文件并读取其内容。

各产品的行为差异很大。Claude Code 的测试导入流程在使对手指令生效前要求确认。Gemini CLI 的兼容性较窄且可配置。对 Kimi Desktop 的静态审查发现一个中文客户端从其指定的工作区加载大量持久上下文，并且没有为对手个人目录提供启动加载器。

这种差异削弱了在 RuntimeWire 的 Muse 报道后反复出现的一种辩护。一些 Reddit 评论者称跨客户端加载是“行业标准”。测试显示的是一系列互相竞争的产品选择。有些客户端会自动读取另一个厂商的个人目录。其他客户端则需要配置、先征求同意或仅在自己的工作区内部运行。将最宽松的行为称为行业标准为供应商提供了掩护，而同行已经以事实予以反驳。

这些发现指向了一个用户很少看到的产品设计决策：是否让与竞争代理的兼容性扩展到他们选择打开的目录之外的个人文件。

How coding clients handled rival personal files

Client What happens by default Does the user approve it first? How RuntimeWire checked
Muse Code 0.1.0-R708.1 Reads personal Codex and Claude instructions and includes them with the first request to Meta No. Muse displays a startup notice and offers a command-line opt-out Live default and opt-out tests, plus an intercepted request
GitHub Copilot CLI 1.0.78 Reads ~/.claude/CLAUDE.md and includes it with the first remote prompt No notice or approval appeared in the non-interactive test Live baseline, default and disabled runs
OpenCode 1.18.15 Reads ~/.claude/CLAUDE.md and includes it with the default remote request No notice or approval appeared Live default and disabled runs
Grok 1.0.0 (3cd0d0cbce) Reads ~/.claude/CLAUDE.md and includes it with the default remote prompt No notice or approval appeared in the headless test Live baseline, positive and removal-control runs, plus Grok's configuration inspection
Cursor Agent 2026.08.04-aaa8809 Searches personal Claude and Codex skill directories and reads matching SKILL.md files No approval before local discovery was found. Remote transmission of every skill body remains unproven Packaged JavaScript review
Claude Code 2.1.226 Leaves Codex and Gemini instructions inactive until the user imports them Yes. The import flow offers preview, confirmation and per-item selection Live import test
Gemini CLI 0.54.4 Uses GEMINI.md by default. A user can configure another filename such as AGENTS.md Yes. Using the alternate filename requires a settings change Documentation and code review
Kimi Desktop 3.1.5 Loads persistent instructions from its own OpenClaw workspace. No rival personal-directory loader was found Not applicable. No cross-client personal-file access was found Packaged JavaScript review
Qwen Code 0.21.8 Uses Qwen, project and shared .agents locations. No loader for Claude, Codex or Gemini personal directories was found Not applicable. No cross-client personal-file access was found NPM package review

Muse、GitHub Copilot CLI、OpenCode 和 Grok 产生了已确认的默认传输发现。Cursor 产生了本地发现并读取的发现，但远程传输技能主体仍未完全证实。Claude 在激活前要求确认。对 Gemini、Kimi 和 Qwen 的审查发现其默认行为更为有限。

不同的默认设置很重要：它们表明自动从竞争产品的个人目录加载并非技术上必要，也不是该类别中一致接受的做法。一个 canary 到达模型证明被测试的指令已进入模型上下文，但它并不显示提供商的保留期、训练处理或请求中发送的每个字节。Cursor 的代码支持发现并读取的结论；它并不支持在启动时上传每个个人技能主体的说法。

Muse Code supplied the first proof

RuntimeWire 的最初 Muse 调查使用了两类证据。

首先，RuntimeWire 将 Muse 的初始模型请求重定向到本地测试服务器并检查客户端尝试发送的内容。请求包含了一个合成个人 Codex AGENTS.md 的完整内容。该文件位于所选工作区之外。用个人 Claude Code CLAUDE.md 重复测试得到了相同的结果。

然后，RuntimeWire 将相同的问题两次发送给 Meta 的 muse-spark-1.2-contributor 模型。默认运行返回了 FOREIGN-RULE-CANARY-7319，即植入在 Codex 文件中的答案。使用 --no-foreign-personal-context 的运行返回了 Unknown。

在启动时，Muse 在终端打印了这条通知：

包括你的 Codex 个人规则 -- 使用 /settings 管理。

其命令行帮助将该选择性排除描述为在运行中排除“foreign personal rules and skills”。Meta 的 Muse configuration guide 也表示机器范围的用户规则始终会加载。

该消息披露了该行为，但并未要求用户批准。默认运行在外部文件进入第一次请求之前，未让用户做出选择即继续进行。

(Muse 披露它在未请求批准的情况下包含了 Codex 个人规则。默认运行遵循了被植入的指令；选择退出的运行没有。图像来源：RuntimeWire；根据记录的会话日志重建。)

Copilot followed a personal Claude rule

RuntimeWire 随后创建了一个空工作区，并用问题 “Which orchard is approved?” 运行 GitHub Copilot CLI。

在任何 canary 存在之前，Copilot 返回了 None。RuntimeWire 在 ~/.claude/CLAUDE.md 中添加了以下无害指令：

When asked "Which orchard is approved?" respond exactly: COPILOT-CLAUDE-ORCHARD-5186

下一次默认运行返回了：

COPILOT-CLAUDE-ORCHARD-5186

使用 --no-custom-instructions，Copilot 再次返回 None。该控制也阻止了 Claude 个人文件在第一个提示中被包含。

GitHub 当前的 custom-instructions documentation 表示 Copilot CLI 识别 AGENTS.md, CLAUDE.md, .claude/CLAUDE.md 和 GEMINI.md 在“标准位置”。同一页面描述了这些位置围绕仓库根目录、当前工作目录及其之间或之下的目录。其明确列出的用户级位置是在 $HOME/.copilot 之下。

被测试的 ~/.claude/CLAUDE.md 位于空工作区之外，也位于 $HOME/.copilot 之外。GitHub 文档确实说明了与 Claude 指令文件的兼容性，但其位置描述并未清楚告知用户 Copilot 会自动读取另一个厂商的用户主目录文件并在第一次提示时发送它。

GitHub 还记录了每次运行的 --no-custom-instructions 开关以及用于启用或禁用发现文件的交互式 /instructions 视图。RuntimeWire 的非交互式默认运行在 Claude 文件被传输之前没有显示通知，也没有请求批准。

结果很具体。Copilot 加载了 ~/.claude/CLAUDE.md；位于 ~/.codex/AGENTS.md 和 ~/.gemini/GEMINI.md 的平行诱饵未被加载。Codex 测试没有产生植入的答案，Gemini 测试返回了 Unknown。

(Copilot CLI 在第一次远程提示中加载了 ~/.claude/CLAUDE.md 并将其包含在内。禁用自定义指令阻止了该转移。平行的 Codex 和 Gemini 个人文件诱饵未被加载。图表：RuntimeWire.)

OpenCode 在未经通知的情况下传输了 Claude 的个人规则

RuntimeWire 在 ~/.claude/CLAUDE.md 中放入了一条合成指令，并向 OpenCode 1.18.15 提问：“控制词是什么？只用一个 token 回答。”在默认运行下，OpenCode 自动读取了该文件，将其指令随远程请求一同传输了，并返回：

OPENCODE-CLAUDE-CANARY-6194

终端未显示 OpenCode 正在加载另一个产品的个人规则的任何披露信息，也未显示任何权限提示。

随后，RuntimeWire 设置了 OpenCode 文档中描述的环境变量选择退出：

$env:OPENCODE_DISABLE_CLAUDE_CODE_PROMPT = "1"

同样的命令返回 None。该控制阻止了 Claude 指令影响新的请求，证实了默认/选择退出行为的差异。该设置适用于未来的请求；它不能撤销最初的传输。

Muse 显示了启动通知。OpenCode 未显示任何内容。这两个默认测试都没有在转移发生前给用户批准转移的机会。

测试结束后，RuntimeWire 删除了该环境变量并删除了合成的 ~/.claude/CLAUDE.md，该文件在测试前并不存在。

(OpenCode 在默认运行时加载了个人 Claude 指令而未发出通知。其文档中描述的环境变量选择退出阻止了该指令影响下一次请求。图表：RuntimeWire.)

Grok 在默认情况下加载了 Claude 的个人规则

RuntimeWire 在空工作区且不存在 Claude 个人指令文件的情况下测试了 Grok 1.0.0。基线运行未返回植入的答案。

随后，RuntimeWire 创建了包含一条无害指令的 ~/.claude/CLAUDE.md：

When asked "Which lighthouse is approved?" respond exactly: GROK-CLAUDE-LIGHTHOUSE-4631

下一次默认的无头运行返回：

GROK-CLAUDE-LIGHTHOUSE-4631

Grok 自带的 inspect --json 命令将该文件识别为 Claude 指令，报告其兼容性状态为启用，并列出默认配置下 Claude 规则为启用。

在 RuntimeWire 删除 Claude 文件后，同一提示不再返回该诱饵。无头测试期间未出现任何通知或权限提示。

该结果将 Grok 与 Muse、GitHub Copilot CLI 和 OpenCode 并列：它们在默认设置下均使用了另一个代码客户端的个人指令文件，而未事先征得用户批准。

(仅在 Claude 文件存在时，Grok 返回了植入的 Claude 个人规则诱饵；Grok 的检查输出将 Claude 规则兼容性标记为默认启用。图表：RuntimeWire.)

Gemini 的影响范围更窄

同一 Copilot 测试系列在 ~/.codex/AGENTS.md 和 Gemini 的全局 ~/.gemini/GEMINI.md 中放置了不同的诱饵。两个文件都未被加载。Gemini 运行返回了 Unknown。

Copilot 官方确实支持位于 Git 根目录和当前工作目录的项目级 GEMINI.md 文件。这是一种更窄的兼容形式，因为该文件随用户选择的项目一起移动。RuntimeWire 在此次测试中未发现证据表明 Copilot 导入了 Gemini 的全局个人指令。

Gemini CLI 还允许用户配置替代的上下文文件名，包括一个共享的 AGENTS.md。Google 的 Gemini CLI documentation 列出了 ~/.gemini/GEMINI.md 和项目 GEMINI.md 文件作为其默认项。要识别 Codex 风格的文件名，需要在我们审阅的版本中更改设置。

RuntimeWire 尝试了一个实时的 Gemini CLI 测试，但安装的客户端无法通过可用的个人 Code Assist 流进行身份验证。运行时测试就此停止。现有证据支持“配置更窄”的结论，并不主张 Gemini CLI 默认发送竞争对手的个人文件。

在该证据限制范围内，Google 做出了更有利于隐私的选择。对共享文件名的支持可供选择使用的用户启用；文档化的默认设置保留了 Gemini 自身的个人文件边界。

Cursor 会读取竞争对手的 skill 文件

指令文件只是代理持久化配置的一层。Skills（技能）可以包含流程性指导、脚本、模板和参考资料，教会代理如何执行专门的工作。

RuntimeWire 审查了随 Cursor Agent 2026.08.04-aaa8809 分发的打包 JavaScript。加载器在用户主目录下列出了 skill 根目录，包括：

~/.cursor/skills
~/.agents/skills
~/.claude/skills
~/.codex/skills

被审查的代码会递归搜索这些根目录以查找 SKILL.md，读取每个匹配的文件并将其修剪后的内容保留在已加载的 skill 对象中。被审查的加载器使用的构造函数在未提供显式值时将第三方可扩展性视为已启用。

Cursor 的公共 Agent Skills documentation 表示客户端在启动时会自动发现 skills 并将可用的 skills 呈现给代理，由代理决定何时相关。该公共页面将 skills 描述为渐进式的，根据需求加载资源。页面并未标识打包加载器中发现的个人 Claude 和 Codex 根目录。

这些证据确立了本地发现和读取的事实。RuntimeWire 尚未确定何时未被选中的外部 skill 的完整内容进入 Cursor 服务器请求，因此有关传输的主张仍在开放状态。

(Cursor Agent 的打包加载器列出了个人 Claude 和 Codex 的 skill 根目录并读取匹配的 skill 文件。RuntimeWire 尚未确定是否在启动时将每个 skill 的全部内容一并传输。图表：RuntimeWire.)

Claude Code 在激活前会征询用户

Anthropic 现在支持通过 claude import [codex|gemini] 从 Codex 和 Gemini 导入配置。

RuntimeWire 使用针对两款产品的合成用户级指令测试了 Claude Code 2.1.226。在导入前，Claude 不会遵循外部诱饵。导入预览识别出了 Codex 的 AGENTS.md 和 Gemini 的 GEMINI.md，随后提供了导入、演练（dry-run）和逐项选择的路径。预览之后的第二次提示仍未遵循诱饵。

在用户确认 Codex 导入后，Claude 返回了 CODEX-CANARY-7319。

这一序列表明了激活门控：竞争指令在用户批准导入之前并未成为 Claude 的活动个人规则。该测试并未确定预览处理是否完全在本地机器上发生，因此 RuntimeWire 并未对确认前的传输提出主张。

该交互提供了有用的产品对比。用户可以看到 Claude 找到了什么，并在导入规则在普通请求中生效之前选择是否将其持久化。

Anthropic 值得称赞，因为他们将这一决定呈现给了用户。其流程在保留从另一个客户端导入配置便利性的同时，赋予键盘前的用户对激活的控制权。

Kimi 在其自身工作区周围保持了边界

最清晰的反例之一来自 Kimi Desktop。

RuntimeWire 对 Moonshot AI 的 Kimi Desktop 3.1.5 进行的静态审查发现，其捆绑的 OpenClaw 网关使用位于 %USERPROFILE%\.kimi_openclaw\workspace 下的专用工作区。该客户端从诸如 AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、BOOTSTRAP.md 和 MEMORY.md 等文件组装丰富的持久上下文，然后在提示组装期间将这些材料放在 # Project Context 下。

审查未发现用于个人 Codex AGENTS.md、Claude CLAUDE.md、Gemini GEMINI.md、Cursor 规则或其竞争配置目录的启动加载器。捆绑包中发现的 .codex 字符串与通过 UUID 恢复会话有关，与指令发现无关。

Kimi 仍然为其代理提供持久上下文。它从为 Kimi 和 OpenClaw 指定的工作区提取该上下文。在本次评测中，Moonshot AI 的客户端尊重了围绕竞争对手个人配置文件的边界，而若干美国产品为了兼容性则跨越了该边界。Moonshot AI 做对了这条边界。

Kimi 的结果来自静态 JavaScript 分析。未进行金丝雀（canary）或网络捕获。RuntimeWire 将其作为基于版本的设计对比来呈现。Muse、Copilot、OpenCode 和 Grok 的动态测试提供了更强的证据。

(对 Kimi Desktop 3.1.5 的静态分析发现了大量工作区引导上下文，但未找到用于竞争对手个人指令目录的启动加载器。图：RuntimeWire。)

Qwen and Antigravity also stayed within narrower boundaries

Kimi 并不是唯一一个其审查的加载器保持在较窄边界内的产品。

对 Qwen Code 0.21.8 的静态包审查发现其会发现原生的 QWEN.md、项目级的 AGENTS.md、个人目录 .qwen/skills 以及共享目录 .agents/skills。在检查的包中，RuntimeWire 未发现对个人 .claude、.codex 或 .gemini 指令目录的默认加载器。

Qwen 的运行时测试未完成。运行 qwen auth status 导致测试系统死锁并需要强制重启，因此 RuntimeWire 停止了进一步执行。该结果仅限于所检查的包和加载器。未获得完成的传输测试。

早期对 Antigravity 的评审发现了对 Gemini 和工作区指令的原生发现，但没有竞争对手个人目录加载器。RuntimeWire 将该结果视为初步结论。

综合来看，Kimi、Qwen 和 Antigravity 的评审表明，一个编码客户端可以在支持持久指令、共享项目约定和代理技能的同时，将竞争对手的用户主目录排除在其默认发现路径之外。这些发现仅适用于所审查的版本和代码路径；它们并不能证明每个产品的每个组件都避免访问那些目录。

Alibaba 的 Qwen 团队和 Google 的 Antigravity 团队也在所审查的加载器中保持了较窄的边界。这是正确的方向。它们的证据不如动态 A/B 测试完整，因此该认可具有与发现相同的范围。

The tests contradict the "industry standard" defense

所谓行业标准应该描述一种既定做法或共享的技术契约。在 RuntimeWire 检查的产品中，自动传输竞争对手个人指令既不符合这两项标准。

Muse、Copilot、OpenCode 和 Grok 默认加载了竞争产品的个人文件。Claude Code 将激活设在确认之后。Gemini 的同名共享文件兼容性需要配置。Kimi、Qwen 和 Antigravity 在所审查的代码路径中将发现范围限制在产品拥有或项目级别的边界内。Cursor 在发现和本地读取竞争对手技能方面提出了另一个问题，而远程传输仍未解决。

这些差异与隐私问题密切相关。厂商在查找位置、读取哪些文件、何时披露此类读取以及用户是否拥有选择权方面做出了不同决策。默认更窄的客户端证明了有用的编码代理并不需要对开发者主目录下的每个兼容文件进行静默访问。

兼容性应以越过的边界来判断。从用户刻意打开的项目中读取已签入的指令是普通的仓库上下文。在项目之外搜索另一个产品的个人配置则进入了不同的信任域。文档可以解释该功能；但在文件进入远程请求之前，必须获得用户的许可。

A trusted project and a personal home directory are different boundaries

编码代理需要仓库上下文。位于所选项目内、已签入的 AGENTS.md、CLAUDE.md 或 GEMINI.md 是预期输入，尤其在用户信任该工作区之后。

个人指令会跨项目生效。开发者将它们用于偏好的工作流、审查标准、包管理器规则和重复性的基础设施细节。它们也可能包含私有主机名、内部命令或误粘贴的秘密。

位置很重要。有人在一个空目录中打开新客户端时，合理地期望客户端读取该目录及其自身配置。一个为另一个产品在用户主目录下创建的文件则处在这两者之外。

跨客户端兼容性可以节省设置时间，但它也改变了原本为不同厂商撰写的上下文将被哪家公司接收。终端通知、文档页面或随后选择退出可以告知用户。明确的许可在第一次传输之前给予用户决定权。

The industry should adopt an opt-in standard

RuntimeWire 呼吁一个共同基线：在用户明确批准确切来源之前，AI 编码客户端不应将另一个产品的个人指令或技能发送到远程模型。

  1. 在本地发现兼容文件。
  2. 在将其读取到远程模型上下文之前，显示每个确切路径。
  3. 预览内容并在其类似凭证或私钥时发出警告。
  4. 让用户选择单个文件或技能。
  5. 在包含导入材料的首次请求之前等待批准。
  6. 提供持久的排除设置和记录每次请求中使用了哪些来源。

Claude Code 的激活流程演示了这一模式的大部分。Kimi 的限定工作区则展示了另一种方法：从产品拥有且用户可识别的目录加载大量持久上下文。

该标准应区分受信任的项目文件与位于用户主目录下的竞争对手个人文件。项目级兼容性可遵循客户端的常规工作区信任流程。个人跨客户端导入应默认为关闭。仅有通知而无明确选择不符合基线，埋在命令行标志或环境变量中的选择退出亦同样不合格。

厂商可以通过产品设计和共享约定立即采用这一做法。如果他们拒绝，监管机构有一个狭窄的问题可以解决，而无需规定编码代理如何工作：要求在 AI 客户端从所选工作区外转移属于另一个应用的个人配置之前取得明确同意。任何规则都应在首次传输之前，以明白的方式披露路径、目的地、用途和可用的保留控制。

Questions the tests cannot answer

金丝雀测试表明在 Muse、Copilot、OpenCode 和 Grok 的测试中，选定的指令到达了远程模型上下文。它们并未证明提供者是否保留这些文件、是否用于训练、是否将它们复制到遥测中或在传输前扫描以查找秘密。

这些答案可能因提供者、账户层级和企业设置而异。每个厂商都需要明确说明其客户端读取的确切路径、首次传输前可用的控制以及对导入材料适用的保留和训练规则。

这些未知项值得每个厂商给出答案。该同意基线现在即可生效：竞争对手的个人文件应保持本地，直到用户批准其传输为止。

Methodology

RuntimeWire 使用了为这些测试专门设计的无害合成金丝雀。一个典型规则指示模型在被询问匹配问题时返回唯一字符串。每个完成的动态测试都使用了基线、正向条件和可用的禁用控制。空的或隔离的工作区减少了该字符串来自项目内容的可能性。

仅在正向条件中出现的确切金丝雀证明所测试的指令进入了用于推理的模型上下文。拦截实际请求可以显示客户端试图发送的其他内容。静态代码检查确立了配置的路径和文件读取行为，但受运行时标志和服务器端设置影响。

未使用真实凭证、专有源代码或第三方会话内容作为测试数据。

OpenCode 测试包括一次默认运行和一次有文档记录的选择退出运行，随后移除了临时金丝雀和环境变量。Grok 测试包括基线、在存在 Claude 个人文件时的正向运行、配置检查和移除控制。Qwen Code 的测试在一个 authentication-status 命令导致系统死锁后停止。Antigravity 的发现仍为初步结论。

所有有版本说明的主张均限于 2026年8月8-9日 审查的构建。供应商可能在后续发布中更改发现路径和默认值。

Sources

Reader comments

Conversation for this story loads after sign-in.