Wrong path when loading plugin skills into cloud environments

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

When Cursor tries to read a plugin skill (or associated files), it fails periodically. The agent’s context contains:

<agent_skill fullPath=“/home/cursor/.cursor/plugins/cache/…/…/…/skills/…/SKILL.md”>

But in a cloud agent, the actual path is /home/ubuntu/… so if the model randomly chooses to read the skill using bash, it fails to find the exact fullPath.

When it loads the Skill using the Read tool, it succeeds.

Steps to Reproduce

Ask a cloud agent to list the items in its <agent_skills> block. It will show paths as /home/cursor/...

Expected Behavior

Paths should be /home/ubuntu/...

Operating System

MacOS

Version Information

Version: 3.7.19
VS Code Extension API: 1.105.1
Commit: 80c653c2c3528e65016a0d304b54486084b470b0
Date: 2026-06-07T01:42:56.126Z
Layout: glass
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.256
OS: Darwin arm64 25.4.0

For AI issues: which model did you use?

Composer 2.5

For AI issues: add Request ID with privacy disabled

bc-1d33fd6c-206a-4a47-81d4-51148c074be9

Additional Information

Workaround: always-on rule to remind Cursor to use its Read tool (or /home/ubuntu/) to read skills and related files.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Thanks for the clear write-up and the request ID. You’ve diagnosed this correctly: in cloud/background agents, the fullPath shown in the <agent_skill> block points at a location that doesn’t exist on the agent’s actual filesystem, so a bash/cat read of that literal path fails. The Read tool resolves skill paths correctly, which is why loading the skill that way works.

This is a real bug on our side, not something in your setup, and we’re getting it fixed. I was able to reproduce it.

In the meantime your workaround is the right one: an always-on rule telling the agent to open skills (and their associated files) with the Read tool rather than shell. Read is the intended way to load skills, so that should keep you unblocked reliably. Pointing it at the real path, as you noted, also works.

I’ll follow up here once the fix ships.