Cloud environment setup: GitLab nested subgroup repo not found (get-repository-branches 400)

[tvanoostrum (Theo van Oostrum)]

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Creating a new Cloud Agent environment for a private GitLab project in a nested subgroup fails before a branch can be selected.

The repo appears in the picker, but Cursor does not resolve a default branch. The branch Select button stays disabled.

POST /api/background-composer/get-repository-branches returns HTTP 400:

{
    "error": {
        "message": "Error",
        "details": [
            {
                "error": "ERROR_BAD_REQUEST",
                "details": {
                    "title": "Bad Request",
                    "detail": "GitLab repository not found: example-org/product-line/Backend/service-api",
                    "isRetryable": false,
                    "additionalInfo": {},
                    "buttons": [],
                    "planChoices": []
                },
                "isExpected": true
            }
        ]
    }
}

Path shape (anonymized, structure preserved): example-org/product-line/Backend/service-api

That is 4 segments: top-level group / subgroup / subgroup / project. The third segment is mixed-case (Backend). The project is private. Default branch is develop (not main).

This is not the closed group-namespace branch-list bug: https://forum.cursor.com/t/gitlab-cloud-agent/143689

That thread was closed after branch listing for group projects was reported fixed (April 2026). This is a remaining repository lookup 400 for a nested subgroup path. GitLab’s own API finds the project and develop; Cursor’s branch endpoint returns “repository not found”.

Likely cause: get-repository-branches does not look up nested GitLab paths correctly. GitLab requires the path encoded as example-org%2Fproduct-line%2FBackend%2Fservice-api, or lookup by numeric project id.

Steps to Reproduce

1. Connect GitLab in Cursor Integrations and sync repos.
2. Open Cloud Agents → create a new environment.
3. Select a private GitLab project with path group/subgroup/SubGroup/project (4 segments, mixed-case subgroup).
4. Try to select a branch / continue setup.

Expected Behavior

Cursor resolves the project, loads branches (including default develop), and enables Select.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

The bug is on Cloud agents. Local versions not applicable

Does this stop you from using Cursor

No - Cursor works, but with this issue

[mohitjain (Mohit)]

Hey @tvanoostrum,

This isn’t caused by anything in your setup, and it’s not the nested-path encoding. Branch listing for a GitLab project currently needs that project to have been synced by someone with Maintainer (or higher) access on it. Projects where you only have Developer access can appear in the picker but fail to load branches, which is what you’re hitting (and why some projects in the group work and others don’t).

To unblock: have a teammate with Maintainer/Owner access on that project open cursor.com/agents and let the repo list load once. That registers it for your whole team and branches should load for everyone, including you. Bumping your own role to Maintainer and reloading works too.

This is an issue we’re tracking. I’ll post back here when there’s an update.