Hey, thanks for the report. The agent screenshot confirms that AGENTS.md is ending up under <agent_requestable_workspace_rules> instead of <always_applied_workspace_rules>. That’s a bug, not a lazy model interpretation. For the AGENTS.md at the project root we should be setting alwaysApply: true, and it should be auto-injected.
How is the project opened? Regular folder, .code-workspace file, multi-root workspace, symlink or mount?
Is AGENTS.md exactly at the project root, or somewhere else like a subfolder or parent directory?
Do you have .cursor/rules/ rules that could conflict?
Privacy Mode won’t give a Request ID, but if you can reproduce this in a test project without Privacy Mode, the Request ID would really help us confirm on the server side what’s actually being sent in the prompt.
Workaround for now: putting @AGENTS.md at the start of the chat forces the content to be injected.
multi-root workspace on local system storage without symlink
directly in project root
I do have local rules, but I don’t know how they could conflict…rules should be instructions sent to the agent and AGENTS.md should be part of the system prompt sent by Cursor, no? Anyway, I don’t really have a rule that says anything about AGENTS.md
Creating a new project doesn’t allow me to override our organization’s privacy settings.
Though…I could copy a request id: 1530ff65-5632-44b4-9614-1df5fd8a7ec1
For what it’s worth I did create a brand new, simple project with a simple AGENTS.md and confirmed the AGENTS.md was not loaded automatically. This was not a multi-root workspace. It was just as simple a setup as I could create.
Hey, thanks for confirming, TomO. The screenshot with “only its path was listed as an agent-requestable workspace rule” matches exactly what @dmwyatt described. So the bug reproduces on both macOS (3.1.15, multi-root and a simple project) and Linux (3.1.17, devcontainer).
@dmwyatt, thanks for the Request ID and for the repro in a simple single-root project. That really helps because it rules out multi-root as the cause.
We’ve filed this internally together with a broader regression around alwaysApply: true rules. It’s not just AGENTS.md, .mdc and .cursorrules behave the same way. I can’t share an ETA for a fix yet, but I’ll post an update in this thread when I have one.
The temporary workaround is still the same. Put @AGENTS.md at the start of your first chat message to force-inject the contents.
Hey, thanks for confirming, TomO. The screenshot with “only its path was listed as an agent-requestable workspace rule” matches exactly what @dmwyatt described. So the bug reproduces on both macOS (3.1.15, multi-root and a simple project) and Linux (3.1.17, devcontainer).
@dmwyatt, thanks for the Request ID and for the repro in a simple single-root project. That really helps because it rules out multi-root as the cause.
We’ve filed this internally together with a broader regression around alwaysApply: true rules. It’s not just AGENTS.md, .mdc and .cursorrules behave the same way. I can’t share an ETA for a fix yet, but I’ll post an update in this thread when I have one.
The temporary workaround is still the same. Put @AGENTS.md at the start of your first chat message to force-inject the contents.
I’d appreciate if your team could treat this as mission critical; in my reading, this affects all customers, completely ignoring all project context (AGENTS.md, CLAUDE.md) and team-/personal-level rules. We’ve had our agents operating erratically for otherwise ‘mysterious’ reasons and developer experience is massively degraded; this also is a recurring issue that occurs after context summarization / compaction, where all of these top-level files are not re-injected into context (and so agents are amnesiac).
This is both a load-bearing element (for ticket / project alignment) and expensive (wasted tokens, developer frustration, blacklisted command execution).
I would have to agree with @SamuelMS . This regression – and especially the fact that Cursor really hasn’t communicated publicly about it or shown urgency to fix it – has led to some office conversations about whether it’s the kind of company we feel comfortable depending on. I’m personally still hoping Cursor steps up and takes ownership today or in the next couple days.
Quick status update so it doesn’t feel like a black box:
The bug is reproducible and has been reported internally (see my post above). The scope is broader than AGENTS.md, all alwaysApply: true rules (.mdc, .cursorrules) behave the same way. This is a regression, not the model ignoring rules.
I separately passed your feedback to the team about severity and the behavior after context compaction or summarization, when top-level files aren’t re-injected. That’s an important signal, thanks for breaking it down. Before, I framed it too narrowly as just affecting the first request.
When we have specifics, we’ll share them here in this thread, not in a separate announcement.
The workaround for now is the same and, unfortunately, not ideal: putting @AGENTS.md at the start of the chat forces injection. If you notice the context gets “forgotten” after compaction, sending @AGENTS.md again in the next message brings the content back into the prompt.
I get that for load-bearing workflows this isn’t a replacement for rules working properly.
Thread update: the fix should land in 3.2. After updating, AGENTS.md (and .mdc / .cursorrules with alwaysApply: true) should show up in <always_applied_workspace_rules> again and be auto-injected.
@dmwyatt@TomO@fan.zhang@SamuelMS@HarryGlaser once you’ve updated, can you please check on your projects and reply here. If anyone still sees that AGENTS.md ends up in agent_requestable_workspace_rules, let me know, ideally with the Request ID if Privacy Mode allows, and we’ll reopen it.
