Why Does Claude Code Skip AGENTS.md Even When Nothing Changed? Three Bug Reports Trace It to the Same Feature Flag (2026)

Claude Code v2.1.277 (September 18, 2026) shipped native AGENTS.md fallback loading. Within five days, three separate GitHub issues — #95589, #96117, and #95690 — documented sessions where the exact same directory, the exact same files, and the exact same settings produced different loading outcomes from one session to the next. The common thread, confirmed by Anthropic’s own live docs as of September 23: AGENTS.md loading isn’t a pure filesystem check. It’s gated behind a remote feature flag (tengu_agents_md_mod, delivered through GrowthBook/Statsig), and that flag has to actually be fetched and fresh before the fallback fires at all.

What Shipped, Briefly

We covered the four Project instructions config values claude-md-or-agents-md ships as when v2.1.277 landed — that piece is the reference for the config surface and the documented CLAUDE.local.md gotcha. This article is about a different layer: the reports filed after that surface was documented, showing the same documented configuration producing non-deterministic results in practice.

Bug 1: Same Directory, Same Version, Different Outcome Every Few Minutes

Issue #95589, filed September 19 against v2.1.278, is the cleanest reproduction. The reporter ran eight sessions in the same directory within 45 minutes — no CLAUDE.md anywhere, only AGENTS.md, default settings, tengu_agents_md_mod confirmed true in ~/.claude.json:

Sessions that load print agents-md: no CLAUDE.md found; AGENTS.md loaded: <paths> at startup. Sessions that don’t load print nothing — no error, no warning, no /config state change. The reporter’s own framing: “The session looks exactly like a project with no instruction files, and the model runs without any of the project’s rules until someone notices the behavior is off.” A side finding in the same report: on sessions where it does load, the user-level ~/.claude/AGENTS.md gets recorded internally as "type": "Project", while the equivalent ~/.claude/CLAUDE.md was recorded as "type": "User" — the fallback path appears to lose the user/project distinction entirely, which matters if you’re relying on that distinction anywhere downstream.

A Community Hypothesis: Stale Flags in Warm Background Daemons

A September 22 comment on that same issue, from a user reproducing it independently, narrows the cause to claude --bg. Claude Code’s background mode keeps a pre-warmed spare process (claude bg-spare) alive and hands it off when you claim a session, rather than booting a fresh process each time. Two --bg sessions, same directory, same version, six minutes apart:

A plain claude -p in the same directory loaded it every single time. The commenter’s own hypothesis, explicitly labeled unverified: feature values read through the bundled GrowthBook helper get pinned in a process-global map on first read, and the claim-time handoff doesn’t reset that map. A spare process that sat idle long enough — 23 hours, in session A’s case — serves whatever flag state it cached at spawn, regardless of what the flag is set to now. Every session that later claims that spare inherits the stale read. It’s a plausible mechanism for exactly the pattern in #95589’s table, but neither report claims to have found the actual pre-claim reader in the bundle, so treat it as the leading theory, not a confirmed root cause.

Bug 2: CLAUDE.local.md Isn’t an Edge Case, It’s a Deterministic Kill Switch

Issue #96117, filed September 22, confirms what the four-values docs mention only briefly: a CLAUDE.local.md anywhere from the working directory up to the project root disables AGENTS.md fallback entirely, including AGENTS.md files in parent directories that have nothing to do with the local note. This report ran the scenario five times each across six configurations and got the same result every time — 5/5, no flakiness, unlike bugs 1 and 3 in this piece:

The reporter traced it to the bundled agents-md plugin’s own source, which lists CLAUDE.local.md alongside CLAUDE.md and .claude/CLAUDE.md in the set of files that switch the fallback off, then walks ancestor directories checking for any match:

var z=["AGENTS.md",".claude/AGENTS.md"];
var C=["CLAUDE.md",".claude/CLAUDE.md","CLAUDE.local.md"];
w = ... || await s.fs.ancestors({names:C}).then((d)=>d.length>0, ...)

A gitignored, personal, per-project file — the thing most teams treat as harmless scratch space for local sandbox URLs — silently zeroes out the shared project instructions for whoever happens to have one, with no notice printed either way. This is deterministic, so once you know about it, it’s easy to work around (switch your own instructionFiles setting to claude-md-and-agents-md, or don’t keep a CLAUDE.local.md in an AGENTS.md-only repo). It’s the flag-dependent bugs 1 and 3 that are harder to catch, because the same fix doesn’t reliably fix them.

Bug 3: The Feature Flag Doesn’t Reach Telemetry-Off, Fresh-Install, or CI Sessions Either

The comment thread on issue #95690 — opened September 20 about the fallback being “a local feature locked behind a remote switch” — accumulated three independent confirmations between September 22 and 23 that go beyond the original report:

• The env var is a footgun. DISABLE_TELEMETRY=0 still disables feature-flag fetching, because Claude Code’s env-var docs specify that any non-empty value — including the strings "0" and "false" — counts as “set.” (DO_NOT_TRACK is the one variable in that family that actually treats 0 as off.) One reporter had to clear both DISABLE_TELEMETRY and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC entirely, and found that setting them in a project’s .claude/settings.json env block doesn’t help — only user settings, --settings, or managed settings are read for this, so there’s no way to opt a single repo in.
• First session after install or upgrade always skips. Confirmed independently on 2.1.278 with a fresh isolated home directory: the very first session never has the flag cached yet, so it reads CLAUDE.md only regardless of what’s configured.
• CI runners are structurally excluded. The same reporter confirmed DISABLE_GROWTHBOOK=1 — a setting CI environments commonly carry — blocks fallback loading every time, calling it “a rollout-gating gap rather than a parser bug.”

Anthropic’s own memory docs and env-vars reference, per timestamps in the thread, were updated September 22–23 to name this skip list explicitly: no feature-flag fetch (telemetry disabled, Bedrock, Vertex, Foundry, or other third-party hosts), the first session after install or upgrade, or a disabled agents-md plugin. In every one of those, /config doesn’t even show the Project instructions row — there’s nothing to toggle.

The Sept 23 Proposal: Stop Gating a File Read Behind a Network Call

Issue #96466, filed the day before this article, ties the whole chain together. It cites #6235 (the original 5,146-👍 request), #34235, #96117, and #95589 by number, and its core ask is direct: make AGENTS.md loading work “wherever and however it loads CLAUDE.md,” with no dependency on feature-flag fetching, so it behaves identically on Bedrock, Vertex, Foundry, with telemetry off, and in the first session after an upgrade. The issue includes its own verification matrix on 2.1.280, confirming that claude-md-and-agents-md (the non-default, always-load-both value) already behaves the way people expect — the problem isn’t the loading logic itself, it’s that the decision to run that logic at all is network-gated. As of this writing the issue has zero comments and is open; there’s no indication Anthropic has picked a side yet.

How to Actually Check Whether Your Session Loaded It

Given all of the above, don’t trust that AGENTS.md loaded just because the docs say it should. Two checks that work, one that doesn’t:

• Works: look for the startup line agents-md: no CLAUDE.md found; AGENTS.md loaded: <paths>. If you don’t see it, it wasn’t loaded that session.
• Works, retroactively: ask Claude directly what its project instructions say, or inspect the session’s .jsonl transcript for an attachment of "type": "instructions".
• Doesn’t work: /context and /memory. Both only list CLAUDE.md-family files — an AGENTS.md pulled in through native fallback never appears there, flaky or not.

What To Do Until This Settles

None of the three bugs above affect the pre-v2.1.277 workaround: a CLAUDE.md containing @AGENTS.md, or a CLAUDE.md symlinked to AGENTS.md. Both load unconditionally, with no feature-flag fetch and no daemon-staleness risk, because they go through the same code path CLAUDE.md always used. If your team is on Bedrock, runs CI with telemetry disabled, or has anyone carrying a CLAUDE.local.md in an AGENTS.md-only repo, keep the import for now — deleting it in favor of the native fallback trades a working, boring mechanism for one that’s still shipping bug fixes five days after launch.

Browse real AGENTS.md and CLAUDE.md files from active repositories, including several that keep the @AGENTS.md import specifically to sidestep this class of bug, in our gallery.

For the full config surface these bugs sit on top of, see Claude Code’s AGENTS.md Support Has Four Config Values. For the backstory of how native support got approved at all, see Claude Code’s Most-Upvoted Issue Hit 5,146 for AGENTS.md Support. For the general debugging playbook across tools, see AGENTS.md Not Loading? How to Debug It.

FAQ

Why does Claude Code load AGENTS.md in one session but not the next, with nothing changed?

Because loading depends on a feature flag (tengu_agents_md_mod) fetched from Anthropic’s GrowthBook/Statsig service, not purely on which files exist. Per issue #95589 and a follow-up hypothesis on the same thread, a stale cached flag value — plausibly from a long-idle claude --bg spare process — can cause a session to silently skip loading even when an identical session moments later loads fine.

Does a CLAUDE.local.md really block AGENTS.md from loading?

Yes, deterministically, per issue #96117’s 5/5-reproducible test matrix. Any CLAUDE.local.md from your working directory up to the project root disables the AGENTS.md fallback entirely under the default claude-md-or-agents-md setting, with no warning printed. Switching to claude-md-and-agents-md, or not keeping a CLAUDE.local.md in an AGENTS.md-only repo, avoids it.

Does DISABLE_TELEMETRY=0 turn feature-flag fetching back on?

No. Per Anthropic’s env-vars documentation, any non-empty value of DISABLE_TELEMETRY — including the string "0" — counts as disabling telemetry, which blocks the feature-flag fetch AGENTS.md fallback depends on. DO_NOT_TRACK is the variable in that family where 0 actually means off.

Will AGENTS.md load in my CI pipeline?

Not reliably under current default settings. CI runners commonly set DISABLE_GROWTHBOOK=1 or disable telemetry, both of which block the feature-flag fetch the fallback needs — confirmed independently in the issue #95690 thread. The @AGENTS.md import or symlink workaround still works in CI because it doesn’t depend on any flag.

Is Anthropic fixing this?

Issue #96466, filed September 23, 2026, proposes removing the feature-flag dependency entirely and making AGENTS.md load the same way CLAUDE.md always has. As of this writing it has no comments from Anthropic staff and remains open, alongside the three bug reports above.