GitLab Cloud Agent environment save returns HTTP 400 despite valid access

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Saving a Personal Cloud Agent environment for the private GitLab repository returns HTTP/2 400.

The GitLab integration is connected . The repository appears after
Sync Repos. The GitLab group is Premium/Ultimate, I have Maintainer
access, and project/group access-token creation is enabled. GitLab also shows
that Cursor created an active project access token for this repository.

The error is therefore misleading and appears to occur after repository access
has already been established.

Steps to Reproduce

  1. Connect the GitLab integration.
  2. Sync repositories.
  3. Create a new Cloud Agent environment.
  4. Select repository.
  5. Select Personal scope.
  6. Click Save and confirm the scope.
  7. The save fails with HTTP/2 400.

Expected Behavior

The environment is saved successfully.

Operating System

MacOS

Version Information

desktop 3.14.27

Additional Information

Response JSON:
{
“error”: “ERROR_BAD_REQUEST”,
“details”: {
“title”: “Bad Request”,
“detail”: “You do not have access to this repository.”,
“isRetryable”: false
}
}

Request path:
/api/background-composer/snapshot-and-save-environment

Request ID:
f9a7046a-279b-47e5-ab48-6e8dc12daba1

x-vercel-id:
fra1::iad1::bv4sj-1785861522914-7aad727033ee

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hey there!
This isn’t something you misconfigured, the 400 is coming from our side.

Two things that should unblock you:

  1. Add yourself as a direct member of that project (or of a genuine parent group of it), Developer or above. The case that trips this up is Maintainer access held only through a group that was invited/shared into the project.
  2. Then disconnect and reconnect the GitLab integration from the Integrations dashboard (Manage → Disconnect → reconnect → Sync Repos), let the sync finish, and save again.

One quick thing to confirm the fix: do you hold Maintainer as a direct project member, via a parent group, or through a group invited/shared into the project? That last case is the one matching what we’re seeing.

We’ve let the team know and this is an issue we’re tracking - I’ll post back here when there’s an update.