AIコーディングクライアントは互いのPersonal Instructionsを読み合っている

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

GitHub Copilot CLIはどの果樹園が承認されたかを知るべきではなかった。

RuntimeWireは答え―― COPILOT-CLAUDE-ORCHARD-5186――をテストユーザーのホームディレクトリ配下にある Claude Code の個人用指示ファイル ~/.claude/CLAUDE.md に置いていた。選択されたワークスペースは空だった。ベースライン実行は None を返した。

次のデフォルト実行で、Copilot は Claude ファイルを読み込み、最初のリモートプロンプトにその指示を含め、植え付けた文字列を正確に返した。RuntimeWire が Copilot の --no-custom-instructions スイッチを付けて同じプロンプトを繰り返したところ、ファイルは除外され、回答は再び None に戻った。非対話のデフォルト実行では送信前に通知は表示されなかった。

この結果は、RuntimeWire が Meta の Muse Code を調査した 8月9日 の報告の続きとなる。その報告 は、Muse がデフォルトで最初の Meta へのリクエストに完全な個人用 Codex と Claude の指示を置いていることを示した。このため、我々はテストを他のコーディングエージェントにも広げた。

拡大調査によりさらに3件のライブ結果が出た。GitHub Copilot CLI、OpenCode、Grok はそれぞれデフォルト設定でテストした Claude の個人用指示を使用した。Cursor Agent の同梱 JavaScript は個人用 Claude と Codex のスキルディレクトリを特定し、再帰的に SKILL.md ファイルを見つけて、その内容を読み取る（サードパーティの拡張機能が有効な場合）。

挙動は製品ごとに大きく異なる。Claude Code のテストされたインポートフローは、競合する指示を有効にする前に確認を待つ。Gemini CLI の互換性は狭く設定可能だった。Kimi Desktop の静的レビューでは、中国のクライアントが自分の指定したワークスペースから広範な永続的コンテキストをロードしており、競合する個人ディレクトリの起動ローダーは見つからなかった。

その差異は、RuntimeWire の Muse レポート後に繰り返し現れた弁明を弱める。Reddit のいくつかのコメント投稿者はクロスクライアントでの読み込みを「業界標準」と呼んだが、テストはむしろ競合する製品の選択肢の集合を示している。一部のクライアントは別ベンダーの個人ディレクトリに自動でアクセスした。他は設定が必要だったり、事前に尋ねたり、独自のワークスペース内に留まったりした。最も許容度の高い挙動を業界標準と呼ぶことは、既に同業他社が反証しているベンダーに免罪符を与えることになる。

これらの発見は、ユーザーがめったに目にしない製品設計上の決断を示している：競合するエージェントとの互換性が、ユーザーが開こうと選択したディレクトリの外にある個人ファイルにまで及ぶかどうか、である。

コーディングクライアントが競合する個人ファイルを扱った方法

Muse、GitHub Copilot CLI、OpenCode、Grok は確認されたデフォルト転送の所見を出した。Cursor はローカルでの発見と読み取りの所見を出したが、リモートへのスキル本文の送信は未解決のままである。Claude は有効化前に確認を求めた。Gemini、Kimi、Qwen のレビューはより限定的なデフォルトを見つけた。

異なるデフォルトは重要だ：それらは、競合する製品の個人ディレクトリから自動的に読み込むことが技術的に必須でも一貫して受け入れられているわけでもないことを示している。カナリアがモデルに到達したことは、テストされた指示がモデルのコンテキストに入ったことを証明する。これはプロバイダの保持期間、トレーニングでの扱い、あるいはリクエストで送られたすべてのバイトを明かすものではない。Cursor のコードは発見と読み取りの所見を支持するが、すべての個人用スキル本文が起動時にアップロードされると主張することは支持しない。

Muse Code が最初の証拠を提供した

RuntimeWire の最初の Muse 調査は2つの証拠形式を使った。

まず、RuntimeWire は Muse の最初のモデルリクエストをローカルのテストサーバにリダイレクトして、クライアントが送信しようとしたものを検査した。リクエストには合成の個人用 Codex AGENTS.md の完全な内容が含まれていた。ファイルは選択されたワークスペースの外に置かれていた。個人用 Claude Code CLAUDE.md で同じテストを繰り返しても同じ結果になった。

その後、RuntimeWire は同じ質問を Meta の muse-spark-1.2-contributor モデルに二度送った。デフォルト実行は Codex ファイルに植えられた答え FOREIGN-RULE-CANARY-7319 を返した。--no-foreign-personal-context を使った実行は Unknown を返した。

起動時に Muse は端末に次の通知を出力した：

Including your Codex personal rules -- manage with /settings.

そのコマンドラインヘルプはオプトアウトを、実行から「foreign personal rules and skills」を除外すると説明している。Meta の Muse configuration guide もまた、マシン全体のユーザールールが常にロードされると述べている。

そのメッセージは挙動を開示したが、ユーザーに承認を求めるものではなかった。デフォルト実行は、外部ファイルが最初のリクエストに入る前にユーザーに選択の機会を与えずに続行した。

Copilot は個人用 Claude ルールに従った

RuntimeWire は空のワークスペースを作成し、GitHub Copilot CLI を使って質問を実行した：「Which orchard is approved?」

カナリアが存在しない状態では、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 ファイルが送信される前に承認は求められなかった。

The result was specific. Copilot loaded ~/.claude/CLAUDE.md; parallel canaries in ~/.codex/AGENTS.md and ~/.gemini/GEMINI.md were not loaded. The Codex test produced no planted answer, and the Gemini test returned Unknown.

OpenCode transmitted Claude's personal rules without notice

RuntimeWire placed a synthetic instruction in ~/.claude/CLAUDE.md and asked OpenCode 1.18.15: "コントロールワードは何ですか？ トークン1つだけで返信してください。" On the default run, OpenCode automatically read the file, transmitted its instruction with the remote request and returned:

OPENCODE-CLAUDE-CANARY-6194

The terminal showed no disclosure that OpenCode was loading another product's personal rules. It also displayed no permission prompt.

RuntimeWire then set OpenCode's documented environment-variable opt-out:

$env:OPENCODE_DISABLE_CLAUDE_CODE_PROMPT = "1"

The same command returned None. The control prevented the Claude instruction from affecting the new request, confirming the default/opt-out difference. It applies to future requests; it cannot undo the initial transmission.

Muse displayed a startup notice. OpenCode displayed nothing. Neither default test gave the user a chance to approve the transfer before it occurred.

After the test, RuntimeWire removed the environment variable and deleted the synthetic ~/.claude/CLAUDE.md, which had not existed before testing.

Grok loaded Claude's personal rules by default

RuntimeWire tested Grok 1.0.0 with an empty workspace and no Claude personal instruction file. The baseline did not return the planted answer.

RuntimeWire then created ~/.claude/CLAUDE.md containing a harmless directive:

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

The next default headless run returned:

GROK-CLAUDE-LIGHTHOUSE-4631

Grok's own inspect --json command identified the file as a Claude instruction, reported its compatibility status as enabled and listed Claude rules as enabled by the default configuration.

After RuntimeWire removed the Claude file, the same prompt no longer returned the canary. No notice or permission prompt appeared during the headless test.

The result places Grok alongside Muse, GitHub Copilot CLI and OpenCode: each used another coding client's personal instruction file under its default settings without first asking the user for approval.

Gemini's reach was narrower

The same Copilot test series placed separate canaries in ~/.codex/AGENTS.md and Gemini's global ~/.gemini/GEMINI.md. Neither file was loaded. The Gemini run returned Unknown.

Copilot does officially support project-level GEMINI.md files in the Git root and current working directory. That is a narrower form of compatibility because the file travels with the project the user selected. RuntimeWire found no evidence in this test that Copilot imported Gemini's global personal instructions.

Gemini CLI also permits users to configure alternate context filenames, including a shared AGENTS.md. Google's Gemini CLI ドキュメント lists ~/.gemini/GEMINI.md and project GEMINI.md files as its defaults. Recognizing a Codex-style filename requires a settings change in the versions we reviewed.

RuntimeWire attempted a live Gemini CLI test, but the installed client could no longer authenticate through the available individual Code Assist flow. The runtime test stopped there. The present evidence supports the narrower configuration finding and no claim that Gemini CLI sent rival personal files by default.

Within that evidentiary limit, Google made the more privacy-protective choice. Support for a shared filename is available to users who choose it; the documented defaults preserve Gemini's own personal-file boundary.

Cursor reads rival skill files

Instruction files are only one layer of an agent's persistent configuration. Skills can contain procedural guidance, scripts, templates and references that teach an agent how to perform specialized work.

RuntimeWire examined the packaged JavaScript distributed with Cursor Agent 2026.08.04-aaa8809. The loader lists skill roots under the user's home directory, including:

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

The examined code recursively searches those roots for SKILL.md, reads each matching file and retains its trimmed content in the loaded skill object. The constructor used by the examined loader treats third-party extensibility as enabled when no explicit value is supplied.

Cursor's public Agent Skills ドキュメント says the client automatically discovers skills at startup and presents available skills to the agent, which decides when they are relevant. The public page describes skills as progressive, loading resources on demand. It does not identify the personal Claude and Codex roots found in the packaged loader.

This evidence establishes local discovery and reading. RuntimeWire has not established when an unselected foreign skill's full body enters a Cursor server request, so the transmission claim remains open.

Claude Code asked before activation

Anthropic now supports importing configuration from Codex and Gemini through claude import [codex|gemini].

RuntimeWire tested Claude Code 2.1.226 with synthetic user-level instructions for both products. Before import, Claude did not follow the foreign canaries. The import preview identified the Codex AGENTS.md and Gemini GEMINI.md, then offered import, dry-run and per-item selection paths. A second prompt after preview still did not follow the canary.

After the user confirmed the Codex import, Claude returned CODEX-CANARY-7319.

The sequence shows activation gating: the competing instruction did not become an active Claude personal rule until the user approved the import. The test does not establish whether preview processing happened entirely on the local machine, so RuntimeWire is making no claim about pre-confirmation transmission.

That interaction offers a useful product comparison. The user sees what Claude found and chooses whether to make it persistent before the imported rule affects ordinary requests.

Anthropic deserves credit for putting that decision in front of the user. Its flow preserves the convenience of importing another client's configuration while giving the person at the keyboard control over activation.

Kimi kept the boundary around its own workspace

One of the clearest counterexamples came from Kimi Desktop.

RuntimeWire's static review of Moonshot AI's Kimi Desktop 3.1.5 found its bundled OpenClaw gateway using a dedicated workspace under %USERPROFILE%\.kimi_openclaw\workspace. The client assembled rich persistent context from files such as AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, BOOTSTRAP.md and MEMORY.md, then placed that material under # Project Context during prompt assembly.

The review found no startup loader for personal Codex AGENTS.md, Claude CLAUDE.md, Gemini GEMINI.md, Cursor rules or their rival configuration directories. A .codex string found in the bundle related to resuming a session by UUID. It was unrelated to instruction discovery.

Kimi still gives its agent persistent context. It draws that context from the workspace designated for Kimi and OpenClaw. In this review, Moonshot AI's client respected the boundary around competitors' personal configuration files while several American products crossed it for compatibility. Moonshot AI got that boundary right.

The Kimi result comes from static JavaScript analysis. No canary or network capture was completed. RuntimeWire is presenting it as a version-specific design comparison. The Muse, Copilot, OpenCode and Grok live tests carry stronger evidence.

Qwen and Antigravity also stayed within narrower boundaries

Kimi was not the only product whose reviewed loader stayed within narrower boundaries.

A static package review of Qwen Code 0.21.8 found discovery for its native QWEN.md, project-level AGENTS.md, personal .qwen/skills and shared .agents/skills. RuntimeWire found no default loader for personal .claude, .codex or .gemini instruction directories in the examined package.

The Qwen runtime test did not finish. Running qwen auth status caused the test system to lock up and require a hard restart, so RuntimeWire stopped further execution. The result is limited to the examined package and loader. No completed transmission test was obtained.

An earlier review of Antigravity found native Gemini and workspace instruction discovery with no rival personal-directory loader. RuntimeWire treats that result as preliminary.

Taken together, the Kimi, Qwen and Antigravity reviews show that a coding client can support persistent instructions, shared project conventions and agent skills while keeping rival user-home directories outside its default discovery path. Those findings apply only to the versions and code paths reviewed; they do not prove that every component of each product avoids those directories.

Alibaba's Qwen team and Google's Antigravity team also kept the reviewed loaders within narrower boundaries. That is the right direction. Their evidence is less complete than the dynamic A/B tests, so the recognition carries the same scope as the finding.

The tests contradict the "industry standard" defense

An industry standard should describe a settled practice or a shared technical contract. Automatic transfer of rival personal instructions meets neither test in the products RuntimeWire examined.

Muse, Copilot, OpenCode and Grok loaded a competing product's personal file by default. Claude Code gated activation behind confirmation. Gemini's shared-filename compatibility required configuration. Kimi, Qwen and Antigravity stayed within product-owned or project-level boundaries in the reviewed code paths. Cursor presents a separate concern around discovery and local reading of rival skills, with remote transmission still unresolved.

These differences are central to the privacy question. Vendors made distinct decisions about where to look, which files to read, when to disclose that reading and whether the user gets a choice. The clients with narrower defaults prove that useful coding agents do not need silent access to every compatible file under a developer's home directory.

Compatibility should be judged by the boundary it crosses. Reading a checked-in instruction from the project a user deliberately opened is ordinary repository context. Searching another product's personal configuration outside that project reaches into a different trust domain. Documentation can explain the feature. Permission must come from the user before the file enters a remote request.

A trusted project and a personal home directory are different boundaries

Coding agents need repository context. A checked-in AGENTS.md, CLAUDE.md or GEMINI.md inside a selected project is an expected input, especially after the user trusts that workspace.

Personal instructions carry across projects. Developers use them for preferred workflows, review standards, package-manager rules and recurring infrastructure details. They can also contain private hostnames, internal commands or secrets pasted by mistake.

The location matters. Someone opening a new client in an empty directory may reasonably expect the client to read that directory and its own configuration. A file created for another product under the user's home directory sits outside both places.

Cross-client compatibility can save setup time. It also changes which company receives context originally written for a different vendor. A terminal notice, documentation page or later opt-out informs the user. Affirmative permission gives the user a decision before the first transfer.

The industry should adopt an opt-in standard

RuntimeWire is calling for a common baseline: an AI coding client should never send another product's personal instructions or skills to a remote model until the user affirmatively approves the exact source.

1. Discover compatible files locally.
2. Show every exact path before reading it into remote model context.
3. Preview the content and warn when it resembles a credential or private key.
4. Let the user select individual files or skills.
5. Wait for approval before the first request containing imported material.
6. Provide a persistent exclusion setting and a record of which sources were used in each request.

Claude Code's activation flow demonstrates much of this pattern. Kimi's scoped workspace shows another approach: load substantial persistent context from a directory the product owns and the user can identify.

The standard should distinguish trusted project files from rival personal files under the user's home directory. Project-level compatibility may follow the client's normal workspace trust process. Personal cross-client imports should default to off. A notice without an affirmative choice fails the baseline, as does an opt-out buried in a command-line flag or environment variable.

Vendors can adopt this immediately through product design and shared conventions. If they decline, regulators have a narrow problem they can address without dictating how coding agents work: require affirmative consent before an AI client transfers personal configuration owned by another application from outside the selected workspace. Any rule should require plain disclosure of the path, destination, purpose and available retention controls before the first transfer.

Questions the tests cannot answer

The canaries establish that selected directives reached remote model context in the Muse, Copilot, OpenCode and Grok tests. They do not establish whether providers retain those files, use them for training, copy them into telemetry or scan them for secrets before transmission.

Those answers can differ by provider, account tier and enterprise setting. Each vendor needs to specify the exact paths its client reads, the controls available before first transfer, and the retention and training rules applied to imported material.

Those unknowns deserve answers from every vendor. The consent baseline can take effect now: rival personal files should remain local until the user approves their transfer.

Methodology

RuntimeWire used harmless, synthetic canaries designed solely for these tests. A typical rule instructed the model to return a unique string when asked a matching question. Each completed dynamic test used a baseline, a positive condition and an available disable control. Empty or isolated workspaces reduced the chance that the string came from project content.

An exact canary appearing only in the positive condition establishes that the tested directive entered the model context used for inference. Intercepting the actual request shows what else the client tried to send. Static code inspection establishes configured paths and file-reading behavior, subject to runtime flags and server-side settings.

No real credentials, proprietary source code or third-party session content was used as test data.

The OpenCode test included a default run and a documented opt-out run, followed by removal of the temporary canary and environment variable. The Grok test included a baseline, a positive run with the Claude personal file present, a configuration inspection and a removal control. Qwen Code testing stopped after an authentication-status command caused a system lockup. The Antigravity finding remains preliminary.

All versioned claims are scoped to the builds examined on Aug. 8-9, 2026. Vendors may change discovery paths and defaults in later releases.

Sources

• RuntimeWire: Muse Code がデフォルトで Codex と Claude のルールを読み込む
• Meta Muse Code の設定
• GitHub Copilot CLI のカスタム指示
• GitHub Copilot CLI コマンドリファレンス
• Cursor Agent Skills ドキュメント
• Claude Code CLI リファレンス
• Gemini CLI のコンテキストファイルドキュメント
• OpenAI Codex AGENTS.md ドキュメント
• Moonshot AI / Kimi
• RuntimeWire Muse Code 0.1.0-R708.1 の傍受されたリクエスト、ライブカナリアテストおよびオプトアウトテスト
• RuntimeWire GitHub Copilot CLI 1.0.78 のベースライン、デフォルト、無効化および並列ファイルテスト
• RuntimeWire OpenCode 1.18.15 のデフォルトおよび環境変数によるオプトアウトテスト
• Grok 1.0.0 の設定検査と RuntimeWire のベースライン、ライブカナリアおよび削除制御テスト
• RuntimeWire Cursor Agent 2026.08.04-aaa8809 のパッケージ化された JavaScript レビュー
• RuntimeWire Claude Code 2.1.226 のインポートおよびアクティベーションテスト
• RuntimeWire Gemini CLI 0.54.4 のドキュメントとコードレビュー
• RuntimeWire Kimi Desktop 3.1.5 のパッケージ化された JavaScript レビュー
• RuntimeWire Qwen Code 0.21.8 のNPMパッケージレビューと不完全なランタイムテスト記録
• RuntimeWire の予備的な Antigravity ローダーのレビュー
• RuntimeWire coding-client の証拠パケットとコマンド記録、2026年8月8–9日