Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
I am reporting a bug where the IDE stops recognizing subagents and user rules, even though the files still exist on disk in the expected locations.
Actual behavior
Subagents
Invoking a subagent with / no longer shows the expected entries—I cannot find the corresponding subagents in the list.
The subagent files still exist under .cursor/agents/.
Opening Settings, I also cannot see those subagents listed there, despite the files being present in the project.
User Rules
Rules stop taking effect in new sessions.
I add explicit instruction in my rules to address me as “尊者” (a honorific). When rules work, opening a new chat and saying “你好” (hello) should result in the model using that form of address. In the bug state, it does not.
When rules are working, hovering over the context meter / usage ring at the bottom shows that rules are active. In the bug scenario, that indication no longer shows that rules are in effect.
Steps to Reproduce
Suspected trigger (unconfirmed): The issue may appear after the Agent has modified existing rules or subagent definitions. This is only a personal hypothesis; I have not fully isolated the cause.
Expected Behavior
Subagents defined under .cursor/agents/ should remain discoverable via / and in Settings as long as the files are valid and in the right place.
User Rules should continue to apply in new sessions, and the UI should still reflect that rules are active (e.g. via the context meter), consistent with a healthy configuration.
Operating System
Linux
Version Information
Version: 3.2.0-pre.32.patch.0 (user setup)
VSCode Version: 1.105.1
Commit: a35c6137b003856e0beea5591910c649f5e97350
Date: 2026-04-16T05:58:50.114Z
Layout: editor
Build Type: Stable
Release Track: Nightly
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100
For AI issues: which model did you use?
all model
For AI issues: add Request ID with privacy disabled
I can’t provide session without privacy cause team demand.
Does this stop you from using Cursor
No - Cursor works, but with this issue
Hi @fan.zhang
A couple of things I noticed:
1. Your .cursor/agents/ is a symlink
From your screenshot, .cursor/agents is a symbolic link pointing to another directory. Cursor may not follow symlinks when scanning for subagent definitions, which would explain why Settings shows “No Subagents Yet” despite files existing at the symlink target. Could you try moving the actual files directly into .cursor/agents/ (replacing the symlink with a real directory) and see if the subagents appear?
2. Rules issue – your build predates the fix
The rules not taking effect is a known regression with alwaysApply: true that was fixed after April 21. Your nightly build is from April 16, so it doesn’t include the fix yet. Updating to the latest nightly should resolve this.
3. Quick question on your OS
You selected “Linux” as your OS, but the version info shows Windows_NT x64 10.0.26100. Are you running Cursor through WSL? If so, that could contribute to file watcher issues with the symlinked agents directory.
Could you try:
-
Updating to the latest nightly build and checking if rules work again
-
Replacing the symlink with a real .cursor/agents/ directory containing your subagent files
-
Confirming whether you’re running via WSL
Hi,
Thanks for the detailed notes. A few follow-ups on my side:
-
Symlink vs. real directory
The agents path actually worked for me with the symlink in the past, and I’ve run into a similar “subagents not showing / not loading” situation even when .cursor/agents was a normal directory, not a symlink. So in my case it doesn’t look like the symlink is the only factor.
-
Nightly / rules
I’ll try updating to the latest nightly, but I suspect this isn’t the same issue as the alwaysApply: true regression. What I usually see is rules breaking and subagents not being available at the same time, which makes it feel like a shared underlying problem rather than the rules fix alone.
-
Environment
I’m not running Cursor inside WSL for this setup. I’m on Windows and I SSH into a remote Linux machine to work on the project there, so the Windows version string in the environment is expected; the workspace itself is on the remote side.
I’ll still replace the symlink with a real folder and bump nightly to rule those out, and I’ll report back if anything changes.
Correction: I tried replacing the symlink with a real agents folder and the subagents came back, so in my case the symlink was likely the cause for the “No Subagents” issue. Sorry for the confusion in my last message.
now the problem back again.
Version: 3.6.12 (user setup)
VS Code Extension API: 1.105.1
Commit: 51897b9a1bad794adb4341746dcb2799071f1780
Date: 2026-05-27T01:47:04.211Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Windows_NT x64 10.0.26100
I can see from your screenshots that the rule file exists on disk with the correct alwaysApply: true frontmatter, but it’s not being included in the agent’s context, while your other User Rules (set in Cursor Settings) are working fine.
This is a known issue that our team is actively investigating. The alwaysApply: true flag in .mdc files is not being reliably honored on current stable builds.
Workarounds for now:
-
Use Cursor Settings > Rules > User Rules — paste your rule content directly into the User Rules text box. Rules set there are always injected (as your screenshot confirms — the settings-based rules are working).
-
@-mention the rule by name in chat to force-include it in the conversation context.
To help narrow down your case, two questions:
-
When you open Cursor Settings > Rules, Skills, Subagents, does address-user-zunzhe.mdc show up in the list? If so, does it say “Always Apply” or “Agent decides”?
-
Could you share a Request ID from a chat where the rule was not applied? (Three dots menu in chat > Copy Request ID)
1、not show
2、b35f6e15-221a-4972-8b54-5da258f93033
Looking for a fast fix — this issue blocks me from coding in Cursor.
Paste your rule content directly into Cursor Settings > Rules > User Rules (the text box). Rules set there are always reliably injected - your screenshot from post #12 confirms the settings-based rules ARE working. You can put the full 称呼用户为尊者 instruction there and it will take effect immediately.
This is a known bug with how Cursor discovers .mdc rule files in ~/.cursor/rules/ on remote SSH sessions. The rule scanner walks upward from your workspace directory, and in certain remote configurations it doesn’t reach your home directory where the rules live. Our engineering team is working on a fix.
One quick question that would help us scope the fix for your case: what’s the path of your remote workspace? (e.g., /home/fan.zhang/project/ or somewhere else like /data/...). This tells us whether the scanner should be reaching your home directory and isn’t, or whether your workspace is outside $HOME entirely.
looks like fixed in cursor 3.7~
