# Title: Cloud Agent on self-hosted worker: Azure DevOps SSH repo label does not match repository URL

**URL:** <https://forum.cursor.com/t/title-cloud-agent-on-self-hosted-worker-azure-devops-ssh-repo-label-does-not-match-repository-url/178184>\
**Category:** Bug Reports\
**Tags:** azure-devops, self-hosted, cloud-agents\
**Created:** [November 12, 2026, 8:14am UTC](https://forum.cursor.com/t/title-cloud-agent-on-self-hosted-worker-azure-devops-ssh-repo-label-does-not-match-repository-url/178184 "2026-11-12T08:14:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Emir\_Hadzimahmutovic](https://avatars.discourse-cdn.com/v4/letter/e/ce73a5/32.png) [@Emir\_Hadzimahmutovic](https://forum.cursor.com/u/Emir_Hadzimahmutovic)\
**Post date:** [November 12, 2026, 8:14am UTC](https://forum.cursor.com/t/title-cloud-agent-on-self-hosted-worker-azure-devops-ssh-repo-label-does-not-match-repository-url/178184/1 "2026-11-12T08:14:42Z")

</div>

### Where does the bug appear (feature/product)?

Cursor CLI

### Describe the Bug

Starting a Cloud Agent against a self-hosted worker for an Azure DevOps repo fails with:  
`Private-worker repo label does not match the repository URL`  
This only happens for the Azure DevOps checkout. GitHub repos on the same machine, same CLI, same `agent worker start` flow work.  
The worker connects and registers. The failure is routing/claim, not worker startup.  
Root cause: the worker CLI and Cursor cloud derive different `repo` identities from the same Azure DevOps origin.

- Local `origin`: `git@ssh.dev.azure.com:v3/{org}/{project}/{repo}`
- Worker-derived `repo` label: `ssh.dev.azure.com/v3/{org}/{project}/{repo}`
- Cloud / Azure DevOps integration canonical URL: `https://dev.azure.com/{org}/{project}/_git/{repo}`
- Cloud also documents Azure repos as `{project}/{repository}` and `org/project/repo`  
Those strings never match. Changing `origin` to HTTPS would break SSH-key git access (no ADO HTTPS credentials on the machine), so that is not a usable workaround.  
This setup worked until recently. Nothing local changed: same SSH remote, same worker dirs, same script. The agent CLI on the worker was `2026.10.14-941492e` (15 Oct). Updating to `2026.11.11-b912975` and restarting the worker did **not** change the label. The new CLI still has no Azure-specific URL canonicalization (`ssh.dev.azure.com` / `v3/...` → `dev.azure.com/.../_git/...`). Known hosts in the worker repo-label parser are still GitHub/GitLab/Bitbucket/etc. only.  
This is the same family as:  
[Remote Control handoff fails for self-hosted Git on a non-standard port: worker repo label mismatch between client CLI and cloud](https://forum.cursor.com/t/remote-control-handoff-fails-for-self-hosted-git-on-a-non-standard-port-worker-repo-label-mismatch-between-client-cli-and-cloud/165122)  
(worker CLI vs cloud normalize the same git origin differently.)

### Steps to Reproduce

1. Clone an Azure DevOps Services repo over SSH:  
`git@ssh.dev.azure.com:v3/{org}/{project}/{repo}`
2. Start a My Machines worker on that checkout:  
`agent worker --name {worker name} --worker-dir /path/to/repo start`
3. Worker log: `Derived repo label from git origin` → `ssh.dev.azure.com/v3/{org}/{project}/{repo}`
4. On [cursor.com/agents](http://cursor.com/agents), select that Azure DevOps repo (connected via Azure DevOps integration) and send the run to the self-hosted worker.

### Expected Behavior

Cloud should treat Azure DevOps SSH (`ssh.dev.azure.com:v3/{org}/{project}/{repo}`) as the same repo as `https://dev.azure.com/{org}/{project}/_git/{repo}` and claim the already-connected worker.

### Screenshots / Screen Recordings

 ![CleanShot 2026-11-12 at 09.10.19@2x.png](https://us1.discourse-cdn.com/cursor1/original/3X/a/9/a93988539c61d13c71986d11f536c3d86b1cdfcf.png)

### Operating System

MacOS

### Version Information

- Cursor IDE: 3.29.15
- Agent CLI: 2026.11.11-b912975 (also reproduced on 2026.10.14-941492e)
- Worker id: `3b5d0a32-d525-43b2-96d2-936fcec99732`

### Additional Information

Worker debug (after CLI update, still the SSH label).

### Does this stop you from using Cursor

Yes - Cursor is unusable

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [November 12, 2026, 10:11am UTC](https://forum.cursor.com/t/title-cloud-agent-on-self-hosted-worker-azure-devops-ssh-repo-label-does-not-match-repository-url/178184/7 "2026-11-12T10:11:57Z")

</div>

Hi @Emir_Hadzimahmutovic, this is on our side, and updating the CLI won’t change it. The cloud now converts Azure DevOps SSH remotes to the `https://dev.azure.com/{org}/{project}/_git/{repo}` form when a run starts, but your worker’s label is still compared in its SSH form, so the start gets rejected. I’ve passed this to the team.

As a workaround, you can point `origin` at the HTTPS form and have git keep using SSH underneath, so your keys still work:

```auto
git remote set-url origin https://dev.azure.com/{org}/{project}/_git/{repo}
git config url."git@ssh.dev.azure.com:v3/{org}/{project}/{repo}".insteadOf "https://dev.azure.com/{org}/{project}/_git/{repo}"

```

Then restart the worker. Its log should show the derived repo label as `dev.azure.com/{org}/{project}/_git/{repo}`, and `git fetch` should still go over SSH. Let me know if the run is still rejected after that.