Affected file: packages/core/src/handlers/clone.ts

Root cause: The SSH-to-HTTPS URL normalization is hardcoded to only handle git@github.com: remotes. Two separate spots in the file do this:

// normalizeRepoUrl() ~line 178
if (normalizedUrl.startsWith('git@github.com:')) {
workingUrl = normalizedUrl.replace('git@github.com:', 'https://github.com/');
}

// registerRepository() ~line 332
if (cleaned.startsWith('git@github.com:')) {
workingRemote = cleaned.replace('git@github.com:', 'https://github.com/');
}
If the remote uses any other host — a custom SSH alias (e.g. github-trabajo), GitHub Enterprise, Gitea, GitLab, Bitbucket — the URL is left as-is. When Archon then splits it by / to extract owner/repo, the portion before the first slash is git@github-trabajo:Third-Opinion, which contains a colon. On Windows, colons are illegal in directory names (except drive letters), so mkdir fails with ENOTDIR and the entire workflow is blocked.

Repro:

Clone a repo whose origin remote is git@<anything-other-than-github.com>:/.git
Run any workflow with --branch
Error:

ENOTDIR: not a directory, mkdir 'C:\Users<user>.archon\workspaces\git@github-trabajo:Third-Opinion\TrialMatch-BE\source'
Fix: Replace the hardcoded string check with a generic SCP-style SSH regex in both locations:

const sshMatch = url.match(/^git@([^:]+):(.+)$/);
if (sshMatch) {
workingUrl = https://${sshMatch[1]}/${sshMatch[2]};
}
This correctly extracts owner/repo regardless of the SSH host alias and produces a path-safe string for the workspace directory. The fix is also needed on Linux/macOS for non-github.com hosts (the mkdir won't fail with ENOTDIR there since colons are valid in Unix paths, but the owner extracted will be malformed — e.g. git@gitlab.company.com:team instead of team).