Cloud Agent fails to launch for GitLab.com repositories when group/project path contains ".com"

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Cursor Cloud Agent incorrectly treats any GitLab path containing “.com” as a self-hosted Git Enterprise instance.

When the repository path on gitlab.com includes a group or project slug with .com (e.g. https://gitlab.com/somedomain.com/my-project), the agent fails with:

We had an issue when trying to launch this cloud agent: Git enterprise instance not found for hostname: somedomain.com. Please set up the enterprise instance in Settings.

This happens even though we are using gitlab.com (paid plan), not a self-hosted instance. The parser seems to split the path on the first .com and assumes it is a custom enterprise hostname.

Steps to Reproduce

  1. Have a GitLab project on gitlab.com whose group or project name contains .com (e.g. somedomain.com/my-project).
  2. In Cursor, follow the Cloud Agent setup from Cloud Agents | Cursor Docs and select the repository.
  3. Attempt to launch the Cloud Agent.
  4. See the “Git enterprise instance not found for hostname: somedomain.com” error.

Workaround that works: Forking the project to a path without .com (e.g. somedomain/my-project) makes the Cloud Agent start correctly.

Expected Behavior

Cursor should parse standard gitlab.com repository paths correctly regardless of whether the group/project slug contains domain-like strings (.com, .io, .org, etc.). The enterprise-hostname detection should only trigger when the remote URL explicitly points to a self-hosted GitLab instance (i.e. not gitlab.com).

Screenshots / Screen Recordings

Snímek obrazovky 2026-02-25 v 10.05.53.png
Snímek obrazovky 2026-02-25 v 10.05.53.png1284×554 48.9 KB

Operating System

Windows 10/11
MacOS
Linux

Version Information

Version: 2.5.25
VSCode Version: 1.105.1
Commit: 7150844152b426ed50d2b68dd6b33b5c5beb73c0
Date: 2026-02-24T07:17:49.417Z (1 day ago)
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Additional Information

We do not want to rename the GitLab group/project just to work around this (the .com is part of our branding/internal naming). Only Cloud Agent is affected.

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the detailed report. This is a clear URL parsing bug. The cloud agent is splitting at the first .com in the full path instead of correctly identifying gitlab.com as the host.

I’ve flagged this with the team.

For now, the workaround you found, forking to a path without .com, is unfortunately the best option until this gets fixed.