Describe the Bug
A user-level workspaceOpen hook returns {“pluginPaths”:[“”]} pointing at a local plugin whose rules use alwaysApply: true (no description). The plugin’s rules do reach agent context, but unreliably, in two distinct ways.
I analyzed 78 per-agent-exec “Cursor Plugins” logs on 3.18.9 (under %APPDATA%\Cursor\logs<session>\window1_wb\exthost\anysphere.cursor-agent-exec):
MODE 1 - delayed registration (62 of 78 hosts)
The “Registered extension plugin: … (extension: cursor-hook)” line appears 27-114 seconds after the host starts (avg 53s). Any chat that starts and does its work inside that window runs with no plugin rules in context.
MODE 2 - never registers (16 of 78 hosts)
The registration line never appears at all. Seven of these hosts lived far longer than the worst-case delay - the longest ran ~37 hours and executed 24 plugin-reload cycles, each one logging “Plugins reload completed: 0 plugins loaded (0 extension, 0 retained), 0 failures”. Waiting or working longer in the session never recovers it. The remaining nine were short-lived (<5 min) and may simply have exited inside the normal delay window; I am not counting those as confirmed.
In both modes there is no error, no warning, and nothing in the UI indicating the plugin has not registered. The agent simply proceeds without the team’s always-on rules and cannot tell they are missing.
Additional signal: every loadAllPlugins line reports total=0 plugins, in both groups - including hosts that register the hook plugin seconds later. The hook-provided plugin evidently arrives through a separate path (extension: cursor-hook) that loadAllPlugins neither counts nor waits on. loadAllPlugins is also sometimes very slow here (9.9s, 11.9s, and up to ~17s observed).
Full breakdown, delay histogram, and redacted log excerpts attached.
Steps to Reproduce
Prerequisites
- A local plugin folder with .cursor-plugin/plugin.json and a rules/*.mdc file that has alwaysApply: true, no description, and a distinctive instruction, e.g. “When the user says ‘plugin smoke test’, reply with exactly PLUGIN_RULE_LOADED and nothing else.”
- A user-level workspaceOpen hook in ~/.cursor/hooks.json that writes a single JSON object to stdout and exits 0:
{“pluginPaths”:[“C:\path\to\my-plugin”]} - Confirm the hook actually runs: have it also append a timestamp to a side-channel log file. It should stamp every window/chat open.
Mode 1 — delayed registration (most hosts)
- Fully quit Cursor and reopen the workspace.
- Immediately (within ~20 seconds) start a new Agent chat and send: plugin smoke test
→ The agent does not have the rule. It typically searches the filesystem for the token instead of echoing it. - Open Output → Cursor Plugins (or the per-host log under %APPDATA%\Cursor\logs<session>\window1_wb\exthost\anysphere.cursor-agent-exec).
→ There is no “Registered extension plugin: … (extension: cursor-hook)” line yet. loadAllPlugins reports total=0. - Wait until that registration line appears (typically 30-110s after the agent-exec host starts). Then start another new chat in the same window and send the same prompt.
→ Often the later chat echoes PLUGIN_RULE_LOADED. This is Mode 1: waiting helps because registration eventually completes.
Mode 2 — never registers (do not skip this; waiting does not recover it)
5. Repeat steps 1-3 on later chats / later windows, not only immediately after a fresh launch. Check the per-host Cursor Plugins log for that chat’s window1_wb folder, not a different host’s log.
→ On some hosts the registration line never appears at all. The log instead cycles “Plugins reload completed: 0 plugins loaded (0 extension, 0 retained), 0 failures” for the host’s entire lifetime.
6. Keep working in that session well past the Mode 1 delay (minutes, not seconds). Send plugin smoke test again in a new chat that shares that same agent-exec host.
→ The agent still does not have the rule. Waiting does not help. On this machine, 7 of 78 hosts stayed in this state for >5 minutes; the longest ran ~37 hours and 24 reload cycles with 0 plugins loaded.
Notes
- The unit of loading is the agent-exec host (window1_wb), not the Cursor window. The same window can have one chat that eventually gets the plugin and another that never does.
- The hook firing is not the bug. The side-channel log stamps every open. The bug is that pluginPaths output is applied late, or not applied to that host at all.
Expected Behavior
-
Plugin registration from workspaceOpen pluginPaths should complete before the first conversation on that agent-exec host can be created, so alwaysApply rules are in context from the first chat.
-
If registration is async, a conversation that starts before it finishes should pick the rules up once registration completes, rather than living its whole life without them. If a host never applies the hook output, that should be an error, not silent “0 plugins loaded” forever.
-
Surface pending or failed registration in the UI. Silently starting a chat with team policy rules missing is the core problem: neither the user nor the agent can tell it happened.
Waiting ~20-110 seconds only covers Mode 1. It does not cover Mode 2, where the host never registers the plugin at all.
Screenshots / Screen Recordings
cursor-pluginpaths-registration-delay.txt (3.46 KB)
Operating System
Windows 10/11
Version Information
Cursor: 3.18.9
OS: Windows 11 Pro, build 10.0.26200
Plan: Enterprise (userLocal=false)
For AI issues: which model did you use?
Not model-specific (context assembly, not generation)
Additional Information
Why this path matters: on-prem / no marketplace for this content, and ~/.cursor/plugins/local is skipped because Allow Local Plugin Imports is off (log shows userLocal=false). That policy is understood; not filing it as a bug. sessionStart additional_context still never reaches the conversation on 3.18.9 (hook runs, JSON is valid). Same as sessionStart hook additional_context is never injected into agent's initial system context — mentioning only as still-reproduces, not a new report.
That leaves workspaceOpen pluginPaths as the remaining Git-based way to ship always-on rules, which is why the registration delay matters.
Distinct from workspaceOpen hook is registered and requested, but the command script never runs (Linux, 3.7.27) — in that report the hook never spawns. Ours spawns reliably and its output is honored; the issue is purely when.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor