Remote SSH: User-level rules not read from WSL $HOME/.cursor

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Description: When connecting to a WSL project from Cursor on Windows via Remote SSH, Cursor reads user-level configuration only from the Windows side (%APPDATA%\Cursor), and does not read configuration from $HOME/.cursor in WSL.

Expected behavior: Support remote-aware user-level rules that read from the remote machine’s home directory, or clearly document this limitation.

Steps to reproduce:

Install Cursor on Windows
Configure user-level rules in WSL: $HOME/.cursor/rules/
Connect to WSL project via Remote SSH from Windows Cursor
Observe that WSL rules are not applied
Workaround: Currently using project-level rules (.cursor/rules/) as a workaround.

Steps to Reproduce

It’s easy to reproduce this:

  1. in wsl, create .cursor/commands/try.md
  2. open cursor from wsl, run cursor
  3. open any project
  4. open cursor chat panel, type /try, then you’ll see no try command recognized
    …
    actually, it doesn’t read the .cursor/* config.
    This is very unfriendly, cursor miss this important feature, remote-aware user level config.

Expected Behavior

read from .cursor/* config when open in wsl.

Operating System

Windows 10/11

Version Information

Version: 3.2.11 (user setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
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
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report.

On the behavior: for personal commands (~/.cursor/commands), this is currently by design. They’re always read from your local machine (Windows side), even when you connect via Remote SSH or WSL. That’s why your try.md in WSL at $HOME/.cursor/commands/ doesn’t get picked up via /try.

Rules are a bit better: .cursor/rules/ can be loaded from remote, but only via an ancestor walk from the workspace path. So if your workspace is under $HOME in WSL and $HOME/.cursor/rules/ is higher up the tree, the rules should load. If your workspace is somewhere under /mnt/... or outside $HOME, they won’t be picked up.

Workarounds for now:

  • Put project-level .cursor/rules/ inside the workspace (what you’re already doing, that’s the right approach).
  • For commands, keep them in .cursor/commands/ inside the project.

About remote-aware user-level config as a feature: we’re aware of it. It was logged internally before, but there’s no timeline yet. If there are updates, I’ll reply in the thread.