Summary
When using Cursor on macOS to connect to a native Windows machine over Remote SSH, Agent Skills do not load at all. This affects both custom project skills and Cursor’s built-in create-skill. According to Cursor docs, project skills should load from .cursor/skills/ or .agents/skills/, so this appears to be a Remote SSH / Windows-specific bug rather than a setup issue.
Expected behavior
Skills should be discovered and usable when placed in supported project directories such as:
• .cursor/skills//SKILL.md
• .agents/skills//SKILL.md
Actual behavior
• Custom skills are not discovered or loaded over Remote SSH.
• Built-in create-skill also does not load.
• Moving the same skill between .cursor/skills/ and .agents/skills/ does not help.
• Placing skills on the remote machine does not help.
• Restarting Cursor and reopening the remote workspace does not fix it.
Steps to Reproduce
On macOS, open Cursor.
Connect to a Windows host using Remote SSH.
Open a remote project folder as the workspace root.
Create a skill at:.cursor/skills/add-alarm-code/SKILL.md
Use a minimal skill file.
Restart Cursor completely.
Reopen the same remote workspace.
Check whether the skill appears in Settings / Rules / Skills and whether it can be invoked.
Repeat the same test under .agents/skills/add-alarm-code/SKILL.md.
Also try invoking Cursor’s built-in create-skill.
Expected Behavior
Observed result
None of the skills load. Even the built-in create-skill is unavailable.
Hey, thanks for the detailed report and the repro steps. It really helps.
This is a known bug. Agent Skills discovery, both custom and the built-in create-skill, is unreliable over Remote SSH. We already have a couple threads with the same symptom:
In SSH mode, the global config ~/.cursor/skills/ is not read, but the project-level .cursor/skills/ in the remote workspace is picked up correctly. This is a confirmed workaround from the team.
A couple questions so we can add more signal for your specific case:
If you open the same workspace locally on the Windows host, without SSH, do the skills get detected?
Can you share logs from View → Output with the Anysphere Remote - SSH channel and the remote Extension Host after restarting Cursor with the remote workspace open? Lines with skill, getManagedSkills, skills-cursor are especially helpful.
Thanks — I have one more important data point that seems to narrow this down:
Repro matrix
Windows → macOS over Remote SSH: skills load normally
macOS → Windows over Remote SSH: skills do not load
In the failing case, even the documented project-level locations do not work:
.cursor/skills//SKILL.md
.agents/skills//SKILL.md
So this does not look like only the known “global ~/.cursor/skills is not read in SSH mode” issue. In my case, the project-level workaround also fails, but only for macOS → native Windows host.
What I verified
directory structure is correct
minimal valid SKILL.md
tested both .cursor/skills/… and .agents/skills/…
built-in create-skill also fails
opposite direction (Windows → macOS) works
Log summary
Remote - SSH looks healthy: SSH connects, remote Cursor Server starts, port forwarding works, no obvious install/handshake failure
Extension Host (Remote) is where things look wrong:
no meaningful managed-skills discovery logs (getManagedSkills, skills-cursor, etc.)
[error] No bundle location found for extension anysphere.cursor-agent
[error] No bundle location found for extension anysphere.cursor-agent-exec
[error] No bundle location found for extension anysphere.cursor-checkout
[error] No bundle location found for extension anysphere.cursor-polyfills-remote
[error] No bundle location found for extension anysphere.cursor-mcp
[error] No bundle location found for extension anysphere.cursor-commits
[error] No bundle location found for extension anysphere.cursor-explorer
[error] No bundle location found for extension anysphere.cursor-retrieval
[error] No bundle location found for extension anysphere.cursor-shadow-workspace
these extensions later report activation success, but the repeated “No bundle location found” errors make it look like remote extension initialization is at least partially broken or inconsistent
also:
[error] Error: command ‘_chat.editSessions.accept’ not found
My conclusion
This seems to be a macOS → Remote SSH → native Windows host regression where the remote extension host / agent initialization is incomplete, so skill discovery never properly starts.
That would explain why:
custom skills fail
built-in create-skill fails
project-level .cursor/skills/… also fails
Would it make sense to track this as a separate Windows-remote-host-specific issue, rather than just the existing “global skills not read in SSH mode” bug?
In Extension Host (Remote), several core Cursor remote extensions first report “No bundle location found”, but then later report activation success in the same startup sequence.
2026-04-19 00:01:45.506 [error] No bundle location found for extension anysphere.cursor-agent
2026-04-19 00:01:45.507 [error] No bundle location found for extension anysphere.cursor-agent-exec
2026-04-19 00:01:45.507 [error] No bundle location found for extension anysphere.cursor-checkout
2026-04-19 00:01:45.507 [error] No bundle location found for extension anysphere.cursor-polyfills-remote
So the pattern is not a simple hard failure. It looks more like:
activation is attempted
bundle resolution fails transiently or inconsistently
the same extensions later report activation success
That makes the remote extension host look partially inconsistent rather than fully broken, which may explain why the SSH connection itself is healthy but skills discovery / agent behavior is still not working correctly on macOS → Remote SSH → native Windows host.
Thanks, this is a really valuable data point. The repro matrix Windows to macOS works, macOS to Windows breaks and especially the log pattern with No bundle location found for anysphere.cursor-agent, cursor-agent-exec, cursor-polyfills-remote, and other core extensions is an important signal that I haven’t seen in the existing skills plus SSH threads.
I agree your interpretation sounds plausible. The symptom might be broader than global ~/.cursor/skills not being readable over SSH which is what we’re tracking right now, and it could affect remote extension host startup in the macOS client to native Windows remote setup. But this is still a hypothesis. Without reproducing it on our side, I can’t say for sure that No bundle location found and missing skill discovery are the same root cause rather than two issues happening at the same time.
I’ll pass these logs and the repro matrix to the team as a separate signal so they look at it beyond the skills bug. I can’t give an ETA for a fix.
A few quick questions to add to the report:
Is the Windows remote a clean Windows setup cmd or PowerShell plus OpenSSH, or are you using WSL, Cygwin, or Git Bash as the SSH shell? Also what Windows version are you on 10 or 11, and which build?
What Cursor Server version is installed on the remote under %USERPROFILE%\.cursor-server\bin\<commit>\?
If you delete %USERPROFILE%\.cursor-server\ entirely on the Windows host and reconnect from the Mac, do you still see No bundle location found on a fresh install?
If you use the same SSH connection to that Windows host from Microsoft VS Code with Remote-SSH, does the core remote extension host start without similar errors? This helps confirm if it’s specific to cursor-server or Anysphere Remote-SSH or a more general remote host issue.
Thanks — here are the answers to your questions, plus two more comparison results:
Windows SSH setup
This is a native Windows machine.
I am not using WSL, Cygwin, or Git Bash.
The SSH server is Windows OpenSSH Server.
It was installed from Windows Optional Features and started as a service via services.msc.
Cursor launches the remote shell with PowerShell, so this repro is in:
macOS client → Remote SSH → native Windows host + Windows OpenSSH Server + PowerShell
Windows version
Windows 10 Pro
22H2
OS build 19045.6466
Remote Cursor Server version
Remote Cursor version: 3.1.15
Remote server commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
Real commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f88
Fresh reinstall test
I did run this.
I completely deleted %USERPROFILE%\.cursor-server\ on the Windows host and reconnected from macOS so Cursor would do a fresh remote server install.
The result is the same: the issue still reproduces after a clean reinstall.
VS Code Remote-SSH comparison
I also tested the same Windows host with Microsoft VS Code + Remote-SSH.
VS Code connects normally, and the remote extension host looks clean there.
I do not see the kind of remote extension initialization errors that appear in Cursor.
I realize VS Code does not have Cursor Skills, so this is not a feature-for-feature comparison, but it still seems useful as a control:
same native Windows host
same general Remote SSH workflow
VS Code remote extension host starts cleanly
Cursor remote extension host shows inconsistent extension initialization in the failing setup
So at this point, this still looks narrower than the currently tracked “global skills not read over SSH” issue, and more like something specific to Cursor’s remote server / remote extension host path in the macOS client → native Windows remote host setup.
Hey, this is really helpful info, especially VS Code as a control on the same host. I’ll pass this to the engineers as a separate signal, not tied to the skills bug. I can’t share an ETA yet.
A couple things for the report:
In the version you sent, there’s a mismatch between the remote commit and the real commit:
Remote server commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
Real commit: ...f88
The last two characters differ. This could be related to No bundle location found if the remote server is looking for bundles in the commit folder, but a different version is actually deployed. Can you check %USERPROFILE%\.cursor-server\bin\ on the Windows host and send the list of subfolders? Also show what’s actually inside bin\<commit>\ for the active commit.
If you can, please attach the full Extension Host Remote log file as a file, not a pasted snippet. The path on the Windows host is usually: %USERPROFILE%\.cursor-server\data\logs\<date>\exthost\exthost.log
Also %USERPROFILE%\.cursor-server\data\logs\<date>\remoteagent.log if it exists.
Once you have those, I’ll attach them to the report. If I get an update on the fix, I’ll reply in the thread.
Under that commit folder I see the normal top-level directories:
bin
extensions
node_modules
out
Inside extensions, the core Cursor remote extension directories are also present on disk, including:
cursor-agent
cursor-agent-exec
cursor-checkout
cursor-commits
cursor-explorer
cursor-mcp
cursor-polyfills-remote
cursor-retrieval
cursor-shadow-workspace
At least from the folder structure, I do not see a separate ...f88 commit directory on disk. So the remote server that is actually installed appears to be under ...f80, while the metadata I sent earlier reports:
That seems consistent with your hypothesis that some part of remote extension bundle resolution may be looking for a different commit/version than the one actually present on disk.
commit vs realCommit in product.json
Based on the bin\ listing, there is no ...f88 folder on disk. All extensions are physically under ...f80, and the structure looks correct. So the mismatch is metadata inside product.json, not a case where the binary points at a different folder. Most likely this is not the root cause of No bundle location found, even though it still looks odd and I’m noting it.
The real signal in the attached logs
It’s not No bundle location found since those extensions activate successfully later. The important part is this:
[warning] [ExtHostCursor] Failed to get credentials for OTLP exporter
Cannot read properties of undefined (reading 'length')
[error] TypeError: Cannot read properties of undefined (reading 'length')
at i5d.getAccessToken (.../Cursor.app/Contents/Resources/app/...)
at Qlb.$getCursorAuthToken / $getAuthId
[error] Extension activation failure: anysphere.cursor-agent-exec
cursor-agent-exec is actually failing during activation because getAccessToken on the macOS client throws a TypeError. Without cursor-agent-exec activated, the whole agent and skills chain won’t start properly. That matches the symptom that skills aren’t discovered, even project-level ones. The stack points to the client side (macOS), not the remote host, which also explains why VS Code Remote-SSH to the same Windows host works fine. There is no cursor-agent-exec there, and that code path doesn’t exist.
I’ll track this as a separate signal that’s not tied to the skills bug. I can’t share an ETA for a fix.
A few follow-ups to add to the report:
On the macOS client, is Privacy Mode enabled in Cursor Settings → Privacy? Also, how did you log in, email and password, GitHub, Google, or SSO for Business or Enterprise?
If you fully sign out and sign back in on macOS, then reconnect over SSH to the same Windows host, does the TypeError in getAccessToken still show up in the extension host logs?
On the macOS client, please collect the client logs, not the remote ones. After reconnecting via SSH, grab:
Help → Toggle Developer Tools → Console
View → Output → Window
Log (Main)
These should include client-level messages showing at what step getAccessToken becomes undefined.
If I get an update on the fix, I’ll reply in the thread.
