Cursor cloud agents are mostly working properly, submitting Github PRs and reacting to update requests etc. However the one thing that is not working is the new feature where screenshots and videos are supposed to be posted on the PR. I can see the agent has taken screenshots and videos and they are being written to the magic /opt directory that I’m assuming the platform is watching in order to automatically post them, but they never appear on the PR.
I have the setting for what to post to PRs set to “Artifacts”, but it also did nothing when it was set to “Links”.
So the overall Github connection to the cloud agents is working fine, but the specific part that is supposed to do the screenshots and videos is not.
Steps to Reproduce
start a cursor remote agent with a request that produces screenshots or videos
Hey, thanks for the report. This is a known issue, and the team is tracking it. The Computer Use feature just launched, so there are still some rough edges with posting artifacts to PRs.
Could you share a link to one of the affected PRs and/or the cloud agent run? That’ll help the team investigate your specific case.
Also, just to confirm, are you running these cloud agents from a Teams/Pro account or Free? And is the repository public or private?
Hi all - posting artifact screenshots to GitHub is not yet supported. They’re currently only viewable within Cursor (IDE, web app, mobile). I’m hoping to build support for it soon.
seeing “Waiting for upload…” indefinitely sounds like a separate issue, will investigate
Seeing the same for our cloud agents. They will test the UI, say they are starting the screen recording, that processing completed but there isn’t a way to view the recording on Cursor web.
Here is an example from this morning:
bc-4a123a6c-9072-4dd6-a1b7-a6dcffb0f742
Let me know if there’s something we can adjust in the prompt to make it more likely.
Here is another example bc-4cf1ae8d-4e5a-4aca-9523-02f1d7d405ad, where it got closer by referencing a file though the tag didn’t render the actual video element.
<recording_ref src="/opt/cursor/artifacts/product_merge_request_full_workflow.mp4">Full workflow: tools index with pending request, creating a new merge request with product search, viewing details, approving and completing the merge</recording_ref>
@neals you’re seeing this issue in Web or in GitHub? can you share screenshots or more information? Feel free to DM. (this recording_ref does not look like a standard thing the agent should be using)
I just deployed this morning the ability for cloud agents to post artifacts to GitHub, requires opt-in in the dashboard: Capabilities | Cursor Docs
Will follow up separately on cases of broken artifacts; it relies on the agent doing the right thing, so we do sometimes see hallucinations or mistakes by the model. Usually the easiest thing is to tell the agent to fix its problem “that video artifact didn’t show up, are you sure its a real file and that you referened it properly?” or similar
Hi @nbradford – following up on this thread with a specific scenario we hit.
We have a custom skill that’s triggered via @cursor comment on an existing GitHub PR to capture a video walkthrough of UI changes. The agent successfully records screenshots and video to /opt/cursor/artifacts/, but the artifacts never render on GitHub.
What we observed on our PR:
The agent couldn’t update the PR description via ManagePullRequest because the PR was created by a human (or local IDE cursor session), not a Cursor cloud agent
It fell back to posting a PR comment with <img src="/opt/cursor/artifacts/..."> tags, but the artifacts rendered as broken references
From our investigation it looks like artifact URL rewriting only happens:
In the PR description (body), not comments
When the write goes through the Cursor platform pipeline (i.e. ManagePullRequest), not via gh pr edit or the GitHub API directly
Two questions:
Is there a way today to embed artifacts on PRs the agent didn’t create? The @cursor trigger on existing PRs is a common pattern for us – code review, demo capture, etc. If ManagePullRequest can’t edit those PR bodies, we’re stuck.
Is artifact rewriting in PR comments on the roadmap? Even if the body limitation persists, supporting rewriting in agent-posted comments would unblock this use case.
Appreciate any guidance on the intended workflow here!
Hey john - you’re quite right about how it all works right now, and this exact use case doesn’t quite work
do you particularly want this manual trigger - have you looked at Automations? I’m assuming your preference is to get the artifacts in the Description itself, the comments only as a fallback if that’s not possible? (i’ll look into letting the ManagePullRequest tool have the ability to add descriptions to PRs it doesn’t own…)
Thanks Nick! Good to know we’re on the right track with our understanding.
We haven’t tried Automations yet for this – would triggering via an Automation fix the artifact embedding issue, or does the same ManagePullRequest ownership limitation apply there too? If Automations solve it, happy to go that route. We’d probably move to automation-triggered demos eventually anyway once we’ve validated the workflow.
Either PR description or comments would work for us. The main thing we care about is being able to trigger demo capture from cloud sessions that don’t own the PR. The @cursor comment trigger on existing PRs is our primary use case right now.
For now we’ve updated our skill to have the agent post a comment summarizing what was demoed and pointing reviewers to click “Open in Web” to view the artifacts in the session. So honestly not a huge pain with the current state of things, just wanted to make sure I wasnt overlooking an easy fix.
If ManagePullRequest gets the ability to edit PRs it doesn’t own, that would be the ideal fix for us. Appreciate you looking into it + the swift response!
