What gets me here is not even the bug itself, it’s the shape of it. A feature that is supposed to read a file from the working directory ends up depending on a remote flag, and when the flag can’t be fetched the fallback is apparently “just act like the file doesn’t exist.” That feels backwards. If I disable telemetry, I expect to lose telemetry. I do not expect the product to quietly stop honoring local instructions.
The part that makes this particularly annoying is the silence. No warning, no “AGENTS.md was skipped because nonessential traffic is off,” just a model that seems to ignore the repo. If you’re debugging this from the outside, of course you start poking at prompts. That’s the trap. The file never made it into the session in the first place.
I also think the privacy story here is muddier than it needs to be. A staged rollout is fine in principle; shipping a local-file feature behind a flag that can’t resolve on privacy-restricted setups is not fine. If the flag must exist, the fallback should be the documented behavior, not disabled behavior. Failing open would be much less surprising than failing closed on a local read.
The workaround the author uses — a one-line CLAUDE.md that imports AGENTS.md — is clever, but it’s also a pretty ugly admission that the new path isn’t trustworthy. Same with the symlink trick for skills. These are the kinds of hacks people reach for when the tool’s defaults don’t line up with how teams actually work.
I’d want to test this myself in a clean repo too, just to see whether the behavior is exactly as brittle as described. But if the measurements hold, this is one of those cases where “technical explanation” is not much of a defense. A local instructions file should not depend on telemetry, full stop.
Reference: Claude Code reads AGENTS.md only when telemetry is on
