Security Reviewer Cloud Agent - Environment Setup hanging

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

I have setup a Security Reviewer agent in the Cursor Dashboard to review Merge Requests in Gitlab. The jobs trigger, but we are seeing it taking an excessive amount of time to set up the environment. Right now, I have an agent running that has been stuck at “Setting Up Environment” for 41 minutes … I started noticing this behavior yesterday afternoon, but it seemed to improve… It was also ok earlier today, but now the issue seems to have started happening again.

Steps to Reproduce

With a trigger rule setup targeting the “PR Opened” event against the relevant repository, open a new Merge Request with changes. Check Security Agents tab in Cursor Dashboard to ensure agent has triggered. After agent triggers, click “view details” to view cloud agent activity, observed it stuck at “Setting up Environment” for over 40 minutes.

Expected Behavior

Set up the review environment and review the changes in the Merge Request.

Operating System

MacOS

Version Information

Version: 3.5.38 (Universal)
VSCode Version: 1.105.1
Commit: 009bb5a3600dd98fe1c1f25798f767f686e14750
Date: 2026-05-26T21:32:06.537Z
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: Darwin arm64 25.3.0

For AI issues: add Request ID with privacy disabled

The relevant request id for this stuck agent is bc-159b8ee2-301a-44b3-88a0-fbf534006a02

Does this stop you from using Cursor

No - Cursor works, but with this issue

hey @sb-rad thanks for your message, and for the request id bc-159b8ee2-301a-44b3-88a0-fbf534006a02, that’s perfect, team will look into it,

if it’s stuck on Setting up environment, the GitLab / Security Reviewer trigger is fine; it’s the cloud VM still bootstrapping (saved env / install / docker). Which environment is the automation on (default, team, personal)? does a normal cloud agent on the same repo hang too? gitlab.com or self-hosted?

Team will be able to check the details with the id for the stuck run, but it’s worth a quick look at the env/build logs if they show up: https://cursor.com/docs/cloud-agent/setup

Team plan, gitlab.com - not self hosted.
We haven’t noticed this behavior with other agents like the vulnerability scanner, but that doesn’t run on-demand, only via cron.