Self-hosted worker online but empty repo list in Agents UI

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Self-hosted worker is connected and visible in the Cloud Agents dashboard with the correct repo label (from git remote). On cursor.com/agents, after selecting Self-hosted, the repository dropdown is empty, so a new agent session cannot be started as described in the self-hosted documentation (“Select the repo that matches your worker”). Our Git is self-managed GitLab on an internal host (VPN-only); there is no public OAuth integration for that GitLab in Cursor.

Steps to Reproduce

Steps to Reproduce

Enable Allow Self-Hosted Agents (team admin).
On a Linux host, clone a repo whose origin is internal GitLab (SSH), install Cursor Agent CLI, run agent worker start --api-key .
Confirm in Cloud Agents dashboard that the worker appears and shows the expected repo.
Open https://cursor.com/agents, same account as the API key.
Choose Self-hosted in the environment dropdown.
Open the repository selector → list is empty (no way to pick the worker’s repo).

Expected Behavior

After choosing Self-hosted, I should be able to select the repo that matches the connected worker (e.g. same group/project as derived from git remote),

Operating System

Linux

Version Information

agent --version
2026.03.25-933d5a6

For AI issues: which model did you use?

N/A — session never starts; no model selected.

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Docs: Self-Hosted Cloud Agents — “Run a task” step 3.
Worker log shows successful auth, Derived repo label from git origin, bridge connected, frames received.
Cloud Agents API (POST /v0/agents) has no documented fields to pick a self-hosted worker / internal GitLab URL

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. This is a known limitation right now. Self-hosted workers with non-GitHub Git providers like a self-managed GitLab behind a VPN are not fully supported in the web UI repo selector yet. The worker connects fine and the dashboard correctly shows the repo label, but the web UI picker is a separate path and it currently does not show worker-reported repos for this setup.

The team is aware of this gap. Your report helps increase visibility, especially since a few other users have hit similar issues with GitLab plus Cloud Agents:

No workaround to offer right now, unfortunately. I flagged this for the team. No ETA, but we are tracking it. I’ll update this thread if there is news.

1 Like
7

Thanks for confirming - good to know it’s a tracked gap rather than a misconfiguration on our side.

Two directions that would unblock self-managed GitLab (VPN) + self-hosted without relying on OAuth’d repos in the web picker:

  1. Agents UI: when Self-hosted is selected, populate the repo list from connected workers (repo label already shown on the dashboard), or allow manual entry of the repo path / a “Start from this worker” action on the worker row.

  2. Cloud Agents API: extend POST /v0/agents with an optional flag or field (e.g. execution: "self_hosted" / workerId / label match) so programmatic and custom UIs can start a session on a specific worker without the web repo selector.

Either would help teams that can’t expose GitLab to Cursor’s OAuth flow. Happy to beta-test when something lands.

1 Like