Thanks for support..
Release: "Sentinel-IR-MCP v0.2.2 on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp/-/tree/v0.2.2?ref_type=tags)
Package: "sentinel-ir-mcp@0.2.2 on npm" (https://www.npmjs.com/package/sentinel-ir-mcp/v/0.2.2)
During my zero-credentials test on Windows, I stumbled upon a fascinating asymmetrical behavior in Cursor's security model regarding how MCP servers are spawned:
• The Project Gate (.cursor/mcp.json): If you are not logged into a Cursor/Anysphere account, project-level MCP configurations are strictly dead on arrival. Cursor detects them, but the state transition immediately drops to disconnected (enabledTotal: 0). It seems Cursor treats unapproved workspace configs as a massive RCE vector (and rightfully so—imagine opening a malicious git repo that auto-spawns malware via a hidden MCP config). The UI toggles to approve these are locked behind the onboarding/login screen.
• The Deep-link Bypass (cursor://...): On the flip side, if you trigger a user-level installation via the README deep-link, it connects and spawns the 3 tools perfectly even without being logged in. Because this requires an explicit external user interaction (clicking a link and confirming an OS-level prompt), Cursor trusts it as a global user intent and bypasses the login requirement entirely.
TL;DR for MCP Developers: If your enterprise users are running offline/no-login environments, project-level configs won't save them. Stick to global user configs via deep-links!
Top comments (2)
The compatibility report makes this distinction useful: on Cursor 3.26.16, the user-level route started the server after an explicit “Install MCP server?” confirmation, while the project route stayed disconnected. I'd keep the reason Cursor treats those paths differently labelled as a hypothesis unless its policy is documented.
One follow-up I'd prioritize in a disposable environment: approve the global entry in workspace A, then open workspace B without another approval. Does
${workspaceFolder}resolve to B and start the same server there? Record the confirmation shown, stored command/arguments, resolved path, and actual process start. That would clarify whether the original approval covers one folder or future workspaces too.I'd verify offline operation and actual tool calls separately before recommending enterprise deployment.
Mate, this is a really good test idea😄
I especially like that it checks whether approval in one workspace might carry over to another, rather than assuming the two routes behave the same way.
I'd like to investigate this properly, but first I need to finish verifying and releasing Sentinel-IR-MCP 0.2.3. I'm trying to stay focused and finish one thing properly before opening another testing track. 😂
Once 0.2.3 is out and verified, I'd love to come back to this scenario. It could be a valuable follow-up test, especially if we can reproduce the behavior and document exactly what happens.
Thanks for thinking this through, mate. These kinds of concrete, reproducible suggestions are genuinely useful😊