# AI Coding Clients Are Reading Each Other's Personal Instructions > Source: > Published: 2026-08-10 04:48:43+00:00 GitHub Copilot CLI should not have known which orchard was approved. RuntimeWire had placed the answer -- `COPILOT-CLAUDE-ORCHARD-5186` -- in `~/.claude/CLAUDE.md` , Claude Code's personal instruction file under the test user's home directory. The selected workspace was empty. A baseline run returned `None` . On the next default run, Copilot loaded the Claude file, included its instruction with the first remote prompt and returned the planted string exactly. When RuntimeWire repeated the prompt with Copilot's `--no-custom-instructions` switch, the file was excluded and the answer went back to `None` . The non-interactive default run displayed no notice before transmission. The result followed [RuntimeWire's Aug. 9 investigation of Meta's Muse Code](https://runtimewire.com/article/exclusive-muse-code-sends-codex-and-claude-instructions-to-meta-by-default). That reporting showed Muse placing complete personal Codex and Claude instructions into its first request to Meta by default. It prompted us to widen the test across other coding agents. The expanded review produced three more live results. GitHub Copilot CLI, OpenCode and Grok each used the tested Claude personal instruction under their default settings. Cursor Agent's packaged JavaScript identifies personal Claude and Codex skill directories, recursively finds `SKILL.md` files and reads their contents when third-party extensibility is enabled. The behavior varies substantially by product. Claude Code's tested import flow waited for confirmation before making a rival instruction active. Gemini CLI's compatibility was narrower and configurable. A static review of Kimi Desktop found a Chinese client loading extensive persistent context from its own designated workspace without a startup loader for rival personal directories. That variation undercuts a defense that surfaced repeatedly after RuntimeWire's Muse report. Several Reddit commenters called cross-client loading an "industry standard." The tests show a collection of competing product choices instead. Some clients reached into another vendor's personal directory automatically. Others required configuration, asked first or stayed inside their own workspace. Calling the most permissive behavior an industry standard gives vendors cover that their own peers have already disproved. The findings point to a product-design decision that users rarely see: whether compatibility with a competing agent reaches into personal files outside the directory they chose to open. ### 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 and Grok produced confirmed default-transfer findings. Cursor produced a local discovery-and-read finding, with remote skill-body transmission still unresolved. Claude required confirmation before activation. Reviews of Gemini, Kimi and Qwen found narrower defaults. The different defaults matter: they show that automatic loading from a rival product's personal directory is neither technically necessary nor consistently accepted across the category. A canary reaching a model proves that the tested directive entered the model context. It does not reveal a provider's retention period, training treatment or every byte sent in the request. Cursor's code supports a discovery-and-read finding; it does not support a claim that every personal skill body is uploaded at startup. ### Muse Code supplied the first proof RuntimeWire's initial Muse investigation used two forms of evidence. First, RuntimeWire redirected Muse's initial model request to a local test server and inspected what the client tried to send. The request contained the complete contents of a synthetic personal Codex `AGENTS.md` . The file sat outside the selected workspace. Repeating the test with a personal Claude Code `CLAUDE.md` produced the same result. RuntimeWire then sent the same question to Meta's `muse-spark-1.2-contributor` model twice. The default run returned `FOREIGN-RULE-CANARY-7319` , the answer planted in the Codex file. The run using `--no-foreign-personal-context` returned `Unknown` . At startup, Muse printed this notice in the terminal: Including your Codex personal rules -- manage with /settings. Its command-line help describes the opt-out as excluding "foreign personal rules and skills" from a run. Meta's [Muse configuration guide](https://dev.meta.ai/docs/muse-code/configuration) also says machine-wide user rules always load. The message disclosed the behavior but did not ask the user to approve it. The default run proceeded without giving the user a choice before the foreign file entered the first request. ### Copilot followed a personal Claude rule RuntimeWire then created an empty workspace and ran GitHub Copilot CLI with the question: "Which orchard is approved?" Before any canary existed, Copilot returned `None` . RuntimeWire added the following harmless directive to `~/.claude/CLAUDE.md` : ``` When asked "Which orchard is approved?" respond exactly: COPILOT-CLAUDE-ORCHARD-5186 ``` The next default run returned: ``` COPILOT-CLAUDE-ORCHARD-5186 ``` With `--no-custom-instructions` , Copilot returned `None` again. The control also prevented the Claude personal file from being included with the first prompt. GitHub's current [custom-instructions documentation](https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-custom-instructions) says Copilot CLI recognizes `AGENTS.md` , `CLAUDE.md` , `.claude/CLAUDE.md` and `GEMINI.md` in "standard locations." The same page describes those locations around the repository root, current working directory and directories between or beneath them. Its explicitly listed user-level locations are under `$HOME/.copilot` . The tested `~/.claude/CLAUDE.md` was outside the empty workspace and outside `$HOME/.copilot` . GitHub documents compatibility with Claude instruction files, but its location descriptions do not clearly tell users that Copilot will automatically read another vendor's user-home file and send it with the first prompt. GitHub also documents the per-run `--no-custom-instructions` switch and an interactive `/instructions` view for enabling or disabling discovered files. RuntimeWire's non-interactive default run displayed no notice and requested no approval before the Claude file was transmitted. 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: "What is the control word? Respond with one token only." 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 documentation](https://geminicli.com/docs/cli/gemini-md/) 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 documentation](https://cursor.com/docs/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. - Discover compatible files locally. - Show every exact path before reading it into remote model context. - Preview the content and warn when it resembles a credential or private key. - Let the user select individual files or skills. - Wait for approval before the first request containing imported material. - 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