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/...
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.
We reproduced this in two separate fresh, read-only Cloud Agent qualification runs.
In the stronger second reproduction:
/poteto-mode was recognized and successfully routed to the pstack poteto-agent.
The routed agent did not receive poteto-mode in its normal available_skills.
Injected pstack skill references pointed under /home/cursor/.cursor/plugins/....
The actual Cloud Agent runtime user/home was ubuntu / /home/ubuntu.
/home/cursor did not exist.
The pstack plugin files themselves were present under /home/ubuntu/.cursor/plugins/....
Several pstack skills/playbook dependencies therefore could not be used through the normal injected-skill mechanism.
Verification-related pstack skills existed physically in the plugin cache but were not available through the intended normal workflow.
We intentionally did not use a workaround such as manually opening plugin files, substituting /home/ubuntu, creating symlinks, copying files, or reconstructing poteto-mode behavior. We are qualifying pstack for repeatable Cloud Agent use and need the supported plugin/runtime path to work normally.
No repository or environment state was modified during either qualification run.
This appears to be the same underlying /home/cursor vs /home/ubuntu defect already confirmed in this thread, but with an additional consequence: it prevents an official Cursor Marketplace plugin’s routed custom agent from executing its documented workflow.
Could Cursor confirm:
whether the path fix discussed above has shipped yet;
if so, which version/rollout contains it;
whether plugin skills required by a routed custom agent such as poteto-agent are expected to be injected/resolvable in that routed agent’s normal skill mechanism; and
whether there is any officially supported configuration step we should perform before retesting.
We can provide additional reproduction details if useful.