[Bug]: git+ssh:// and ssh+git:// remotes keep the SSH port and produce malformed merge request and commit links

Start with parseGitRemoteHost in packages/source-control-core/src/shared/definition.ts, parseGitRemoteRepository in packages/shared/src/git.ts, and isSshRemoteUrl in packages/shared/src/sourceControl.ts; the reproduction script exercises the resolver and link builders. Read the existing SSH port test in packages/source-control-gitlab/src/shared/definition.test.ts and run the supplied reproduction to see the defect. Done means both compound SSH spellings resolve like ssh:// while HTTP(S) ports remain intact; the issue lists focused tests to check.

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

Use a checkout of the commit under Version or commit with its locked dependencies installed. From the top-level checkout directory, run the script below with env -u NODE_ENV sh repro.sh. It creates one temporary Git repository with a private HOME, TMPDIR and T3CODE_HOME, resolves its origin through the production RepositoryIdentityResolver (real Node ProcessRunner, real git), and passes the identity to the production client functions projectChangeRequestUrl, projectCommitUrl and resolvePullRequestPreviewTarget. It repeats this for ssh://, git+ssh:// and ssh+git:// with the same user, host, port 2222 and repository path. No forge account, network connection or running server is needed. The script exits 0 when the ssh:// control is correct and both compound spellings show the wrong values, so its assertions pin the current defect.

#!/bin/sh
set -eu
checkout=$PWD
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' EXIT HUP INT TERM
mkdir -p "$tmp/userhome" "$tmp/tmp" "$tmp/t3" "$tmp/repo"
export HOME="$tmp/userhome" TMPDIR="$tmp/tmp" T3CODE_HOME="$tmp/t3" FIXTURE="$tmp/repo"
export GIT_CONFIG_NOSYSTEM=1 GIT_CONFIG_GLOBAL=/dev/null
unset GIT_DIR GIT_WORK_TREE GIT_COMMON_DIR GIT_INDEX_FILE GIT_OBJECT_DIRECTORY GIT_ALTERNATE_OBJECT_DIRECTORIES
git -C "$FIXTURE" init -q
git -C "$FIXTURE" remote add origin ssh://[email protected]:2222/group/repo.git
cd "$checkout/apps/server"
env -u NODE_ENV node --input-type=module <<'JS'
import assert from 'node:assert/strict';
import { execFileSync } from 'node:child_process';
import * as NodeServices from '@effect/platform-node/NodeServices';
import * as Effect from 'effect/Effect';
import * as Resolver from './src/project/RepositoryIdentityResolver.ts';
import { builtInSourceControlDefinitions as registry } from '../../packages/source-control-definitions/src/registry.ts';
import { projectChangeRequestUrl, projectCommitUrl, resolvePullRequestPreviewTarget } from '../../packages/client-runtime/src/changeRequestLinks.ts';
await Effect.runPromise(Effect.gen(function* () {
  const resolver = yield* Resolver.RepositoryIdentityResolver;
  for (const scheme of ['ssh', 'git+ssh', 'ssh+git']) {
    const remote = `${scheme}://[email protected]:2222/group/repo.git`;
    execFileSync('git', ['-C', process.env.FIXTURE, 'remote', 'set-url', 'origin', remote]);
    const identity = yield* resolver.resolve(process.env.FIXTURE, { refresh: true });
    assert(identity);
    const url = 'https://gitlab.example.test/group/repo/-/merge_requests/7';
    const preview = resolvePullRequestPreviewTarget({url, projects: [{id: 'project', environmentId: 'local', repositoryIdentity: identity}], environmentId: 'local', pullRequestsEnabled: true});
    const result = {
      scheme, baseUrl: registry.recognizeRemote(remote)?.baseUrl,
      key: identity.canonicalKey, label: identity.displayName,
      mr: projectChangeRequestUrl(identity, registry.repositorySelector(identity), 7),
      commit: projectCommitUrl(identity, 'a'.repeat(40)),
      preview: preview?.input ?? null,
    };
    console.log(JSON.stringify(result, null, 2));
    if (scheme === 'ssh') {
      assert.equal(result.baseUrl, 'https://gitlab.example.test');
      assert.equal(result.key, 'gitlab.example.test/group/repo');
      assert.equal(result.mr, url);
      assert(preview);
    } else {
      assert.equal(result.baseUrl, 'https://gitlab.example.test:2222');
      assert.equal(result.key, `${scheme}://[email protected]:2222/group/repo`);
      assert.equal(preview, null);
    }
  }
}).pipe(Effect.provide(Resolver.layer), Effect.provide(NodeServices.layer)));
JS

Expected behavior

All three URLs name the same SSH transport and repository, so they should produce the same identity as the ssh:// control: provider base URL https://gitlab.example.test, canonical key gitlab.example.test/group/repo, label group/repo, ordinary HTTPS merge request and commit links, and a preview target for https://gitlab.example.test/group/repo/-/merge_requests/7. The GitRemoteHost host contract says an SSH remote never contributes its port to the provider host, and an existing GitLab regression test pins that for ssh://. Git maps both compound spellings to SSH while marking them deprecated in its transport URL parser. In a local probe with an argument-recording SSH program, Git invoked SSH with the same user, host, -p 2222 and git-upload-pack arguments for all three spellings; the probe made no connection.

Actual behavior

Summary. A project whose Git remote uses the git+ssh:// or ssh+git:// spelling of an SSH URL gets a wrong repository identity. Git treats both spellings as SSH, but T3 Code handles them as web URLs: with a custom SSH port, the recognized provider base URL keeps that port (https://gitlab.example.test:2222), the canonical repository key stays the raw git+ssh://... URL, the project label becomes /[email protected]:2222/group/repo, and the client's merge request and commit link builders produce malformed URLs such as https://git+ssh://[email protected]:2222/group/repo/-/merge_requests/7. The project's real HTTPS merge request URL then gets no in-app link or preview target. The same remote spelled ssh:// resolves correctly. Git marks both compound spellings as deprecated but still accepts them; how often projects use them is unknown.

The ssh:// control produces the expected identity, links and preview target. Both compound spellings still recognize the provider as gitlab, but keep :2222 in the provider base URL, keep the compound URL as the canonical key, and produce the malformed links and null preview shown under Logs or stack traces. The link builders split the canonical key at /, so they read git+ssh: or ssh+git: as the host.

This path is reachable in normal use: ProjectEnrichmentService calls the resolver, which reads the project's Git remotes and builds its identity through shared recognition and normalization. The client functions have production callers in the diff panel's commit link, the fallback merge request URL and in-app merge request opening. No browser click, rendered UI or authenticated provider operation was tested, so this report does not claim an observed HTTP error or that every pull request feature fails.

Code locators, as breadcrumbs rather than a prescribed fix: parseGitRemoteHost drops the port only when the URL protocol is literally ssh:; parseGitRemoteRepository accepts only the ssh, http, https and git URL schemes, so compound URLs fall back to the raw URL as the key; and isSshRemoteUrl accepts SCP-style and literal ssh:// remotes only, so its callers classify compound remotes as web remotes. The client link builders then consume the malformed key. Correcting only the base URL would not restore the key, label or links.

Evidence

• Expected source: the GitRemoteHost.host contract in packages/source-control-core/src/shared/definition.ts lines 81-89, the ssh:// port regression in packages/source-control-gitlab/src/shared/definition.test.ts lines 111-126, the ssh:// control in the reproduction, and Git's url.c mapping of both compound spellings to SSH.
• Failure source: the reproduction output under Logs or stack traces, produced by the production RepositoryIdentityResolver and client link and preview functions.
• Evidence provenance: observed
• Local verification: reproduced
• Reproduction completeness: complete

The script above passed at the baseline commit from a clean checkout. On upstream main, a longer variant of the same script that also records Git's SSH arguments showed the same defect and the same working ssh:// control; the script above was not rerun there. The existing focused tests packages/shared/src/sourceControl.test.ts, packages/source-control-gitlab/src/shared/definition.test.ts and apps/server/src/project/RepositoryIdentityResolver.test.ts pass (31 tests), so none of them covers the compound spellings.

Related

Merged #12537 dropped the SSH port for ssh:// remotes while keeping explicit ports for other URL schemes; its discussion does not mention the compound spellings. Closed, unmerged #14919 proposed normalizing compound spellings as part of broader SSH alias support and was closed because main had moved, not on product grounds; it did not change the port guard in parseGitRemoteHost. Open #29011 (explicit ports in HTTP pull request links), #31781 (SSH remotes with a single path component) and #33899 (SSH environment ports in editor links) concern different inputs and do not handle these spellings.

Restoration check

With the script's input, git+ssh://[email protected]:2222/group/repo.git and ssh+git://[email protected]:2222/group/repo.git produce the same values as the ssh:// control: base URL https://gitlab.example.test, key gitlab.example.test/group/repo, label group/repo, merge request link https://gitlab.example.test/group/repo/-/merge_requests/7, commit link https://gitlab.example.test/group/repo/-/commit/<sha>, and a non-null preview with host gitlab.example.test and repository group/repo. (The script's compound-spelling assertions encode the current defect and will fail once it is fixed.) The ssh:// control and the existing ssh:// port regression keep passing, and HTTP(S) remotes keep their explicit ports.

Impact

Minor bug or occasional failure

Version or commit

T3 Code 0.1.9 at d9805b2ca667be7caec8c9035950564ab96704c3, rerun from a clean checkout; also reproduced on upstream main at 4fd40e1a16e3800418b8f6a32932b68179098c8d, where parseGitRemoteHost, isSshRemoteUrl and the parseGitRemoteRepository scheme list are unchanged.

Environment

macOS on arm64, Node v26.12.1, production server and client functions with real temporary Git repositories, no browser, server or provider credentials.

Logs or stack traces

The script's output:

{
  "scheme": "ssh",
  "baseUrl": "https://gitlab.example.test",
  "key": "gitlab.example.test/group/repo",
  "label": "group/repo",
  "mr": "https://gitlab.example.test/group/repo/-/merge_requests/7",
  "commit": "https://gitlab.example.test/group/repo/-/commit/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "preview": {
    "projectId": "project",
    "host": "gitlab.example.test",
    "repository": "group/repo",
    "number": 7
  }
}
{
  "scheme": "git+ssh",
  "baseUrl": "https://gitlab.example.test:2222",
  "key": "git+ssh://[email protected]:2222/group/repo",
  "label": "/[email protected]:2222/group/repo",
  "mr": "https://git+ssh://[email protected]:2222/group/repo/-/merge_requests/7",
  "commit": "https://git+ssh//[email protected]:2222/group/repo/-/commit/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "preview": null
}
{
  "scheme": "ssh+git",
  "baseUrl": "https://gitlab.example.test:2222",
  "key": "ssh+git://[email protected]:2222/group/repo",
  "label": "/[email protected]:2222/group/repo",
  "mr": "https://ssh+git://[email protected]:2222/group/repo/-/merge_requests/7",
  "commit": "https://ssh+git//[email protected]:2222/group/repo/-/commit/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "preview": null
}

Screenshots, recordings, or supporting files

No response

Workaround

Change the remote to the ssh:// spelling with the same user, host, port and path, for example git remote set-url origin ssh://[email protected]:2222/group/repo.git. The reproduction shows that spelling resolving correctly through the same service and client functions. When a running client picks up the corrected identity was not tested.