Summary

• Problem: normalizeRepoUrl() and registerRepository() only matched git@github.com: literally. SSH URLs with any other host (custom aliases, GHE, Gitea, GitLab, Bitbucket) were left as git@<host>:owner/repo, producing workspace paths with literal git@<host>: segments. On Windows the colon makes mkdir fail with ENOTDIR; on Unix the owner extraction is malformed.
• Why it matters: any user with a non-default SSH host alias (single-machine multi-account is the common case) cannot clone or register a repository at all on Windows, and gets a git@host:owner directory on Unix.
• What changed: two-site swap of cleaned.startsWith('git@github.com:') for the SCP-style regex /^git@([^:]+):(.+)$/. The github.com path is identical; non-github SSH hosts now convert to path-safe HTTPS.
• What did not change: GH_TOKEN injection still gates on workingUrl.includes('github.com') so non-github HTTPS URLs are not authenticated with a GH token. Local-path and HTTPS code paths are untouched.

UX Journey

Before

User remote                       Archon                        Result
───────────                       ──────                        ──────
git@github.com:o/r          ───▶  startsWith match  ───▶  https://github.com/o/r  ✓
git@gh-work:o/r             ───▶  startsWith MISS   ───▶  git@gh-work:o/r         ✗
git@gitlab.company.com:t/p  ───▶  startsWith MISS   ───▶  git@gitlab.company.com:t/p  ✗
                                                          (workspace mkdir fails on Windows
                                                           with ENOTDIR; owner is malformed
                                                           on Unix)

After

User remote                       Archon                        Result
───────────                       ──────                        ──────
git@github.com:o/r          ───▶  /^git@([^:]+):(.+)$/  ───▶  https://github.com/o/r        ✓
git@gh-work:o/r             ───▶  /^git@([^:]+):(.+)$/  ───▶  https://gh-work/o/r           ✓
git@gitlab.company.com:t/p  ───▶  /^git@([^:]+):(.+)$/  ───▶  https://gitlab.company.com/t/p  ✓

Architecture Diagram

Before

   ┌─────────────────────────────────────┐
   │  cloneRepository / registerRepo     │
   │                                     │
   │  ┌─────────────────────────────┐    │
   │  │ normalizeRepoUrl  (clone)   │    │
   │  │  if startsWith('git@        │    │
   │  │     github.com:')           │    │
   │  │    replace literal prefix   │    │
   │  └─────────────────────────────┘    │
   │                                     │
   │  ┌─────────────────────────────┐    │
   │  │ registerRepository (reg)    │    │
   │  │  if startsWith('git@        │    │
   │  │     github.com:')           │    │
   │  │    replace literal prefix   │    │
   │  └─────────────────────────────┘    │
   └─────────────────────────────────────┘

After

   ┌─────────────────────────────────────┐
   │  cloneRepository / registerRepo     │
   │                                     │
   │  ┌─────────────────────────────┐    │
   │  │ normalizeRepoUrl  (clone)   │    │
   │  │  [~ /^git@([^:]+):(.+)$/]   │    │
   │  │    rebuild https://$1/$2    │    │
   │  └─────────────────────────────┘    │
   │                                     │
   │  ┌─────────────────────────────┐    │
   │  │ registerRepository (reg)    │    │
   │  │  [~ /^git@([^:]+):(.+)$/]   │    │
   │  │    rebuild https://$1/$2    │    │
   │  └─────────────────────────────┘    │
   └─────────────────────────────────────┘

Connection inventory:

Label Snapshot

• Risk: risk: low
• Size: size: XS
• Scope: core
• Module: core:handlers/clone

Change Metadata

• Change type: bug
• Primary scope: core

Linked Issue

• Closes Bug: SSH URLs with custom host aliases fail workspace registration on Windows #1614

Validation Evidence (required)

bun test packages/core/src/handlers/clone.test.ts
# 46 pass, 0 fail, 75 expect() calls, 449ms

bun run type-check
# all packages: Exited with code 0

bun x prettier --check .
# All matched files use Prettier code style!

bun x eslint --max-warnings 0 --no-warn-ignored \
  packages/core/src/handlers/clone.ts \
  packages/core/src/handlers/clone.test.ts
# (clean)

The full-monorepo bun run lint OOMs the Node ESLint process on this branch and on a clean checkout of upstream/main (pre-existing on this machine), so it is run scoped to the two touched files. The same OOM also blocks running the full test suite to completion; the file-scoped clone.test.ts run passes all 46 tests including the two new ones for custom-alias and non-github SSH hosts.

Security Impact (required)

• New permissions/capabilities? No
• New external network calls? No
• Secrets/tokens handling changed? No (GH_TOKEN injection logic is untouched; still gates on workingUrl.includes('github.com'), so a git@gh-work:o/r URL converted to https://gh-work/o/r will not receive a GitHub token; a custom alias whose name contains the substring github.com would, but that is pre-existing behavior in this file)
• File system access scope changed? No

Compatibility / Migration

• Backward compatible? Yes. The github.com case produces the byte-identical URL https://github.com/owner/repo it did before.
• Config/env changes? No
• Database migration needed? No

Human Verification (required)

Verified scenarios in clone.test.ts:

• git@github.com:owner/repo.git → https://github.com/owner/repo (regression test, unchanged behavior)
• git@github.com:owner/repo.git with GH_TOKEN=ghp_… → token-injected HTTPS URL (regression test, unchanged behavior)
• git@gh-work:owner/repo.git → https://gh-work/owner/repo (new test)
• git@gitlab.example.com:team/project.git → https://gitlab.example.com/team/project (new test)

Edge cases checked:

• Existing SSH-not-converted assertions (not.toContain('git@')) still hold under the regex.
• Existing GH_TOKEN test for git@github.com: still hits the github.com substring guard.

What was not verified:

• A Windows machine (the original reporter's failure surface). The path-safety claim is structural: the only character the regex emits in the host slot is [^:], so the output cannot contain a colon.
• IPv6-literal hosts in SSH URLs (git@[::1]:owner/repo). Out of scope and not part of any existing call site.

Side Effects / Blast Radius (required)

• Affected subsystems/workflows: any caller of cloneRepository(url) or registerRepository(localPath) whose remote is an SSH URL. github.com remotes are byte-identical.
• Potential unintended effects: a custom SSH alias whose name contains the literal substring github.com (e.g. git@github.com-work:o/r) would now produce https://github.com-work/o/r, which on the existing workingUrl.includes('github.com') check would still trigger GH_TOKEN injection. This is the same loose-substring behavior the file has today on HTTPS URLs; not a regression.
• Guardrails/monitoring: two unit tests guard the new shapes; existing tests guard the github.com shape.

Rollback Plan (required)

• Fast rollback: git revert <merge-sha> on dev. The two match() blocks are local to this commit.
• Feature flags or config toggles: none.
• Observable failure symptoms: workspace mkdir fails or owner is malformed on a non-github SSH URL (the original Bug: SSH URLs with custom host aliases fail workspace registration on Windows #1614 symptom returns).

Risks and Mitigations

• Risk: a remote URL that begins with the literal characters git@ but is not an SSH URL (e.g. a username happens to be git in a non-SSH context) would match the regex. Mitigation: SCP-style SSH grammar is <user>@<host>:<path>, and the git@ prefix plus colon plus non-empty path is the canonical form for git SSH remotes; the previous code also matched only on the git@ prefix, so the input class accepted here is strictly a superset of what the previous code accepted.

Summary by CodeRabbit

• New Features
  • Extended SSH repository URL support for custom Git host aliases and non-GitHub Git services. SSH URLs are now automatically converted to HTTPS format across repository operations.