When registering a new private repo via the Web UI's URL form, the clone step in handlers/clone.ts only injects the auth token when the URL contains github.com. Private repos hosted on GitLab (self-hosted or gitlab.com), Gitea, or any other forge attempt to clone unauthenticated and fail.

The relevant logic substitutes credentials only on a github.com substring match:

if (ghToken && workingUrl.includes('github.com')) {
  cloneUrl = workingUrl.replace('https://github.com', `https://${ghToken}@github.com`);
}

Impact

Users with self-hosted GitLab or private gitlab.com repos cannot register projects via the Web UI URL form. Current workarounds:

1. Use the chat orchestrator, which has GITLAB_TOKEN in its env and constructs an authenticated clone URL itself.
2. Embed the token directly in the URL (https://oauth2:<TOKEN>@host/...) — exposed in any UI history.
3. Clone manually on the host and register the existing directory by file path.

All three work, but the Web UI's URL-form path is the most discoverable entry point and silently fails for non-GitHub users.

Suggested direction (not prescriptive)

Replace the substring match with URL hostname parsing, resolve the auth token from a per-host convention (GITHUB_TOKEN, GITLAB_TOKEN, GITEA_TOKEN, etc.), and apply the appropriate auth URL scheme per host:

• GitHub: https://<TOKEN>@github.com/...
• GitLab: https://oauth2:<TOKEN>@<host>/...
• Gitea/Forgejo: https://<USER>:<TOKEN>@<host>/...

Happy to send a PR if this direction aligns with how you're thinking about multi-forge support generally. I see #1104 is doing similar work for workflow commands; this clone path is separate but the same overall goal of forge-agnostic handling.

Environment

Self-hosted GitLab on custom domain, Archon running in Docker, GITLAB_TOKEN and GITLAB_URL already set in env (used successfully by the orchestrator path).