[BUG] Desktop sidebar: sessions from GitLab subgroup repos never group by project on a second device (always land in "Other")

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

On a second machine, the Code tab groups Remote Control sessions by project. Sessions whose repository lives on GitHub (`owner/repo`) group correctly. Sessions whose repository lives in a GitLab **subgroup** (`group/subgroup/repo`) always land in the **Other** bucket, regardless of what the local checkout looks like.

Grouping on the second device appears to be derived from the git remote rather than from the local path, and a three-segment GitLab path seems not to be parsed into a project identity.

**Setup:** machine A ("origin") runs the sessions in the CLI and exposes them with `/remote-control`. Machine B ("viewer") shows them in the Code tab of Claude Desktop, same account, grouping set to group by project (the default). On machine A every session groups correctly, using the local folder name. On machine B only the GitHub-backed ones group.

| origin remote | remote path shape | group on machine B |
| --- | --- | --- |
| `git@github.com:acme/web-admin.git` | `owner/repo` | `web-admin` ✅ |
| `https://github.com/acme/web-frontend` | `owner/repo` | `web-frontend` ✅ |
| `https://github.com/other-user/web-site.git` | `owner/repo` | `web-site` ✅ |
| `git@gitlab.com:acme-dev/middleware/cruncher.git` | `group/subgroup/repo` | **Other** ❌ |
| `https://gitlab.com/acme-dev/middleware/pricing-importer.git` | `group/subgroup/repo` | **Other** ❌ |
| `git@gitlab.com:acme-dev/internal/lifecycle-manager.git` | `group/subgroup/repo` | **Other** ❌ |

Protocol is not the factor: GitHub works over both SSH and HTTPS, GitLab fails over both.

### The local path is not the factor either

This is the part that rules out the obvious explanation. Local checkout paths on the two machines:

| repo | machine A | machine B | grouped on B |
| --- | --- | --- | --- |
| `web-admin` (GitHub) | `~/Web/acme/web-admin` | `~/Web/web-admin` | ✅ yes |
| `cruncher` (GitLab subgroup) | `~/Web/vendor/cruncher` | `~/Web/vendor/cruncher` | ❌ no |

The GitHub repo has a **different** absolute path on the two machines and still groups. The GitLab repo has an **identical** absolute path on both, is fully cloned on machine B, and still does not. So neither the presence of the local folder nor a matching path explains the behaviour — the only variable that tracks the outcome is the shape of the remote URL.

Every repo in our GitLab organisation lives inside a subgroup, so on the second device the entire work half of the sidebar collapses into one undifferentiated **Other** list (~10 sessions), while personal GitHub projects group correctly. The affected sessions are exactly the ones most worth reaching from a second machine.

(Org and repo names above are anonymised; the path shapes are verbatim.)

### What Should Happen?

Both sessions group under their respective project on the second device, the same way they do on the machine the sessions actually run on.

Actual: the GitHub-backed session groups under its repo name; the GitLab-backed session lands in **Other**, alongside sessions that have no repository at all (idle Remote Control sessions still carrying their auto-generated `--` placeholder names).

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. On machine A, clone two repos: one hosted in a GitLab subgroup (`gitlab.com///`) and one hosted on GitHub (`github.com//`).
2. Start `claude` in each checkout and run `/remote-control` in both.
3. On machine B, signed in to the same account, open Claude Desktop → Code tab, with grouping set to group by project (the default).
4. Look at the sidebar.

Observed: the GitHub session is grouped under its repo name. The GitLab session is in **Other**.

This reproduces regardless of whether the GitLab repo is also cloned on machine B, and regardless of whether its absolute path there matches machine A.

### Claude Model

None

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

Claude Desktop 1.46388.4 (50e62f), build 2026-09-05 — this is a Desktop app bug, so the version is from the app's About dialog rather than `claude --version`

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

### Workaround attempted, and why it does not help

The session context menu offers **Move to group** / create a new group. Moving a session into a manually created group does work — but switching to manual grouping **discards the automatically derived groups**, and every other session drops into **Ungrouped**. Switching back to group-by-project restores the automatic groups and silently ignores the manual assignment.

Manual grouping is therefore all-or-nothing, and cannot be used to patch up individual projects while leaving automatic grouping in place for the rest.

### Possibly related

#92612 reports the opposite failure mode — sessions from two different hosts merged into one group because they share an identical absolute path. Both suggest the cross-device project identity is derived from something narrower than "repo on host X", but they are different symptoms and I don't think this is a duplicate.

### Open question

I have no GitLab repo outside a subgroup, so I cannot tell whether the parser fails on `gitlab.com` generally or specifically on three-segment subgroup paths. Happy to test a plain `gitlab.com//` remote if that would help narrow it down.

Start at the /remote-control entry point and the Claude Desktop Code tab, then trace how cross-device sessions derive project groups from git remotes. Reproduce with the listed GitHub and GitLab subgroup URL shapes on two devices. Done means GitLab subgroup sessions group under their project on the second device, matching GitHub behavior without moving unrelated sessions into Other.

Escrita pelo modelo de indexação a partir do texto da issue.