Claude Code skips AGENTS.md when telemetry is off

If you run Claude Code with telemetry off, the AGENTS.md in your repo may never reach the model, and Claude Code won't tell you. A write-up on Szypowi traces the cause to a remote feature flag that decides whether a plugin may read a file already sitting on your own disk.

At a glance

• Claude Code 2.1.277 announced that projects without a CLAUDE.md would fall back to AGENTS.md. According to the Szypowi write-up and GitHub issue #95690, users who disable telemetry get nothing.
• The loader is a built-in plugin, agents-md. It checks a remote flag named tengu_agents_md_mod and treats a flag it can't fetch as false, so DISABLE_TELEMETRY=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 switches it off.
• Nothing warns you when the file is skipped, and Bedrock, Vertex and gateway users hit the same wall. For now, the dependable workaround is a one-line CLAUDE.md that imports AGENTS.md.

AGENTS.md is a plain markdown file of project instructions that other coding agents, Codex among them, also read. That way one file can serve every tool in a repo. Claude Code has long used its own CLAUDE.md for the same job. Version 2.1.277 announced that Claude Code would read AGENTS.md instead when a project has no CLAUDE.md, which should have spared people from keeping two files in sync.

A remote flag named tengu_agents_md_mod decides whether a local file loads

The author keeps telemetry off in their shell and noticed that the file never loaded in their repos. Issue #95690 explained why. The author added their own measurements to the issue and then collected them in one post. In the 2.1.280 bundle, the loader ships as a built-in plugin called agents-md, and two values in its registration matter.

The first, isOnByDefault, is set to false. The second, isAvailable, asks a remote feature flag named tengu_agents_md_mod and falls back to false. When Claude Code can't fetch that flag, the plugin counts as unavailable and AGENTS.md is never read. Reading a markdown file from the working directory needs no network at all.

Either DISABLE_TELEMETRY=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 blocks the file, and setting them to 0 doesn't undo it

The test was simple. An empty directory held only an AGENTS.md with the line "The canary word is PERIWINKLE." Then claude -p was asked for the canary word from the project instructions, told to answer NONE if it had none, and told not to read files. Each setup ran in two sessions, because the first session in a new configuration only fetches the flag and the second one uses it.

With either variable set, the word never came back, so the author had to clear both. Setting either one to 0 left the block in place. The environment variable docs say any value counts, which is easy to miss when you're trying to turn something on. An env block in the project's .claude/settings.json that cleared both variables had no effect, so there is no switch for a single repo.

One setup did work, from the second session on: a session-level override passed as claude --settings, with both variables set to empty strings in its env block. None of the failing setups printed a warning. The issue also says Bedrock, Vertex and third-party gateways have the same problem, because the flag can't resolve to true there either.

Why a one-line CLAUDE.md gets around the flag

Picture a door that only opens when head office buzzes it. The file sits right behind the door, but with the line to head office down, the door stays shut and no sign tells you it's locked. CLAUDE.md never goes through that door, because its imports are handled on a different path.

CLAUDE.md supports @path imports, and those don't depend on the flag. Put a CLAUDE.md containing only @AGENTS.md next to the AGENTS.md, and the canary test returns the word even with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 still set. The cost is one extra file per repo, which is exactly what AGENTS.md support was supposed to remove.

Personal instructions have a similar gap. The plugin looks for AGENTS.md and .claude/AGENTS.md in project directories only, and there is no user-level file next to the user CLAUDE.md. Codex reads a global ~/.codex/AGENTS.md, and the /import command in Claude Code can copy it into the user CLAUDE.md. The copy doesn't follow later edits, though. An @ import in the user CLAUDE.md that points at the shared file does.

Claude Code 2.1.280 doesn't list skills kept in .agents/skills

Codex reads skills from .agents/skills in the project and from ~/.agents/skills in the home directory. Claude Code 2.1.280 knows those paths only inside /import, which copies the skills into .claude/skills. The author put a canary skill in .agents/skills, and Claude Code didn't list it. In the same repo, it did list the same skill from .claude/skills.

A copy drifts away from its source, so the author links .claude/skills to ../.agents/skills instead, and Claude Code follows that symlink. The author's current setup is the one-line CLAUDE.md for instructions and a symlink for skills.

The bundle shows the flag and its fallback, but not why Anthropic gates a local file read. A staged rollout is only the author's conditional guess. In our view, the fallback is the real design flaw: when the flag can't be fetched, the feature silently turns off and no startup message appears. The people it hits are likely the ones who care most about AGENTS.md, including teams that disable nonessential traffic by policy.

What issue #95690 still has to settle

No fixed version or date has been named. The author asks for three things. First, AGENTS.md loading that doesn't depend on telemetry, or at least a startup warning when an AGENTS.md is present and skipped. Second, a global AGENTS.md at user level. Third, native reading of shared skills from .agents/skills. Until one of these ships, check whether either variable is set in your shell before you start rewriting prompts.