# Turn Off Claude Code Telemetry, and AGENTS.md Can Disappear **Summary:** Claude Code 2.1.277 added native AGENTS.md support, but telemetry-disabled sessions may never load it. I would keep a one-line CLAUDE.md import until local instructions have a local fallback. - Canonical: https://markhuang.ai/news/claude-code-agents-md-telemetry-gate - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-23 - Section: News - Tags: Claude Code, AGENTS.md, Developer Tools, Telemetry, Repository Instructions - Source: [Przemyslaw Szypowicz](https://blog.szypowi.cz/p/claude-code-reads-agents.md-only-when-telemetry-is-on/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A glowing local instruction file reaches an AI coding core through a direct path while a remote gate stays closed](https://cdn.markhuang.ai/news/claude-code-agents-md-telemetry-gate/hero.webp) *A local instruction file should not need a remote switch to reach the coding agent.* Claude Code 2.1.277 added native `AGENTS.md` support. Five days later, [Przemyslaw Szypowicz documented an awkward condition attached to it](https://blog.szypowi.cz/p/claude-code-reads-agents.md-only-when-telemetry-is-on/): with telemetry or nonessential traffic disabled, his local instruction file never loaded. The session carried on without a warning. My earlier read was that [Claude Code treats AGENTS.md as Plan B](https://markhuang.ai/news/claude-code-agents-md-is-plan-b) whenever a project already has `CLAUDE.md`. This evidence puts another branch before that choice. Some sessions never get the built-in `agents-md` feature at all. I would no longer treat the file's presence as proof that Claude received it. ## The local file depends on a remote decision Szypowicz inspected the 2.1.280 bundle and found that the built-in plugin was unavailable by default unless a remote feature flag enabled it. He then created an otherwise empty directory, put a canary word in `AGENTS.md`, and asked `claude -p` to return the word without reading files. His test used two sessions for each setup because the first session fetched the flag and the second used it. With either `DISABLE_TELEMETRY=1` or `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1`, the canary did not arrive. Clearing both variables restored the feature from the second session onward. This is one developer's controlled reproduction, not a broad fleet study, but Anthropic's own [current documentation describes the same boundary](https://code.claude.com/docs/en/memory#when-agentsmd-support-is-unavailable). It says direct loading requires version 2.1.277 or later and can be unavailable when a session cannot fetch feature flags, including telemetry-disabled sessions and some third-party-provider setups. An [open issue in Anthropic's repository](https://github.com/anthropics/claude-code/issues/95690), filed September 20, reports that the feature flag cannot resolve to true when nonessential traffic is disabled or when Claude Code runs through certain gateways, Bedrock, or Vertex. The issue is evidence of a reported defect, not an Anthropic confirmation. The official documentation is the stronger support for the limitation. > **Warning:** > > The dangerous outcome is not a crash. Claude Code still answers, so a missing review rule or forbidden command can look like model disobedience when the instruction never entered the context. ## Privacy controls should not rewrite local behavior I understand why Anthropic would stage a new loader behind a feature flag. Version 2.1.277 was a rollout, and the same documentation notes that the first session after an install or upgrade may not have support yet. The part I cannot defend is the silent fallback. A switch that limits outbound traffic should not quietly change whether a local Markdown file is read. The implementation makes debugging harder because three explanations now produce similar symptoms. Claude might have loaded the file and failed to follow it. A nearby `CLAUDE.md` might have taken precedence. Or the `agents-md` feature might never have been available. Telling those apart requires checking configuration and planting a canary, which is too much detective work for a repository convention. The obvious counterargument is that feature flags are temporary and a one-line compatibility file is cheap. The file is cheap. The uncertainty isn't. Repository instructions can contain test commands, directory boundaries, and review requirements. If the loader skips them, the product should say so at startup and name the reason. ## I would keep the boring import Szypowicz's workaround is the one I would ship today. Put a `CLAUDE.md` beside `AGENTS.md` and give it one import: ```text @AGENTS.md ``` Anthropic's documentation recommends the same route for sessions where direct support is unavailable. It also says the import does not make Claude read the file twice when native loading works. That lets `AGENTS.md` remain the shared source of truth while `CLAUDE.md` acts as a small compatibility adapter. I would test the arrangement with one harmless, distinctive instruction and check `/memory` on Claude Code 2.1.280 or later. Anthropic notes that earlier releases did not list directly loaded `AGENTS.md` files there, so the canary still matters on 2.1.277 through 2.1.279. I would also leave the import in place for Bedrock, Vertex, gateway, and telemetry-disabled workflows until the official limitation disappears. Native support is useful only if the same repository instruction file survives the privacy settings and providers a team uses in production. For now, I would keep the extra line. It costs less than debugging rules that never reached the agent.