Claude Code Was Silently Skipping Your AGENTS.md the Whole Time You Had Telemetry Off
Claude Code added support for AGENTS.md in version 2.1.277, and for anyone who runs with telemetry disabled, it has never actually worked. The file gets skipped entirely, no error, no warning, the agent just proceeds as if your instructions don't exist. It took until September 23 for someone to trace the cause and publish it, and as of today the GitHub issue tracking it is still open with no fix shipped.
What's actually broken
The bug is almost funny once you see the mechanism. Reading a markdown file off your own disk is about as local an operation as software gets. But Claude Code's AGENTS.md support is gated behind a remote Statsig feature flag called tengu_agents_md_mod, and that flag has to resolve over the network before the local read is allowed to happen. Set DISABLE_TELEMETRY=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, either of which blocks that flag check, and the file read never fires. No fallback, no console warning. The agent behaves exactly as it would if AGENTS.md didn't exist in your project at all.
The same failure hits anyone routing through a third-party gateway, Bedrock, or Vertex AI, since those paths don't hit the same telemetry pipeline either. GitHub issue #95690 marks the severity as "data loss or corrupted project" and notes it reproduces 100% of the time on the affected version. That's a strong claim for what looks, on paper, like a config-loading nit.
Why this is the bug that finds you late
I disable telemetry on most of my own tooling by default, and I'd guess a meaningful share of this blog's readers do the same, whether for bandwidth reasons, client confidentiality, or just not wanting a coding agent phoning home about what's in a private repo. That's precisely the population this bug hits, and it hits silently. You write a careful AGENTS.md describing your project's conventions, commit it, and the agent just never reads it. Nothing crashes. Nothing looks wrong in the transcript. You only notice when the agent's output starts drifting from what you specified, and by then you're debugging the wrong problem: you're checking your prompt, your model choice, your context window, when the actual issue is a network flag that never resolved.
That's a rough failure mode for a feature that exists specifically to make agent behavior more predictable. A config file that governs how an AI agent acts on your code should never depend on a live network call to a vendor's experiment platform. If the flag check times out, errors, or gets blocked by a firewall, corporate proxy, or a user's own privacy settings, the correct behavior is to still read the file that's sitting right there on disk, not to fail closed with zero signal.
The workaround, and why it's not really a fix
There's a documented one-line patch you can apply today: create a CLAUDE.md in your project root containing just @AGENTS.md. Claude Code's import syntax pulls in the referenced file's content directly, and that import path doesn't appear to depend on the same remote flag. It works. I tested it against a project where I'd already confirmed the direct AGENTS.md read was being skipped, and the import brought the instructions in correctly.
But that's a workaround, not a fix, and it puts the burden on every user who's opted out of telemetry to know this bug exists and know the exact incantation to route around it. Most won't. Most will just have an agent that ignores their instructions some of the time, for reasons that never surface in any log.
What I'd actually do
If you use Claude Code and you've disabled telemetry or you're routing through Bedrock or Vertex, add the CLAUDE.md importing @AGENTS.md today. It costs you one file and thirty seconds, and it closes a gap that otherwise fails silently in exactly the way that's hardest to debug. Don't wait for the upstream fix. Issue #95690 has no timeline attached as of this writing, and even once Anthropic ships a patch, you'll still want the defensive habit of not letting a purely local operation depend on a remote flag you don't control.
The honest counter-take here: it's possible Anthropic considers the feature flag intentional, a staged rollout mechanism rather than a bug, and that the real fix is just widening the rollout rather than removing the network dependency. If that's the case, the core complaint stands regardless: a local file read should degrade gracefully, not silently, when the flag check fails for any reason.
Author
Lukas
@lukcombinator