[Bug]: GitLab clones default to SSH even when glab is configured for HTTPS

The logic is in packages/client-runtime/src/operations/projects.ts in the getDefaultCloneUrl function. Compare with the GitHub/Forgejo handling. Check how glab config get git_protocol is read. The fix likely involves adding 'gitlab' to the condition or reading the CLI config. Test by cloning a GitLab repo after the change.

Before submitting

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

Related: #4203 (same problem for GitHub, closed as fixed by #7760).

Area

apps/web

(Also affects apps/mobile. The logic lives in packages/client-runtime/src/operations/projects.ts.)

Steps to reproduce

On a headless Linux host where GitLab is set up for HTTPS only, which is the glab default:

1. glab auth login and choose HTTPS. glab config get git_protocol --host gitlab.com prints https, and ~/.gitconfig gets credential.https://gitlab.com.helper = !glab auth git-credential.
2. Have no SSH key registered with GitLab, and no gitlab.com entry in ~/.ssh/known_hosts.
3. In T3 Code: Add Project → Clone → GitLab, enter user/project.

Expected behavior

The clone uses HTTPS (https://gitlab.com/user/project.git) and authenticates through the glab credential helper, the same as GitHub clones since #7760. At minimum, it should respect glab's configured git_protocol.

Actual behavior

The lookup succeeds, but the clone uses the SSH URL (git@gitlab.com:user/project.git) and fails:

Failed to clone project
Host key verification failed. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.

The cause is getDefaultCloneUrl, which returns the HTTPS URL only for GitHub (and Forgejo on main):

/** GitHub and Forgejo default to HTTPS; other providers retain their existing SSH default. */
export function getDefaultCloneUrl(repository) {
  return repository.provider === "github" || repository.provider === "forgejo"
    ? repository.url
    : repository.sshUrl;
}

The reasoning behind #4203/#7760 applies to GitLab just as much. The user has authenticated the CLI over HTTPS, the credential helper is already configured, and SSH needs separate key and host-key setup that a headless host often lacks. There is no UI option to choose the protocol, so the clone can't succeed without changes outside T3.

Suggested fix: include gitlab in the HTTPS branch, or more generally default to HTTPS for every provider whose CLI is configured for HTTPS (glab config get git_protocol, gh config get git_protocol) and fall back to SSH only when the CLI says ssh.

Workaround: rewrite GitLab SSH URLs to HTTPS in git:

git config --global url."https://gitlab.com/".insteadOf "git@gitlab.com:"

After that, git ls-remote git@gitlab.com:<private group>/<project>.git succeeds through the glab credential helper, and the T3 clone works.

Impact

Major degradation or frequent failure

Version or commit

t3@0.0.42. Also still present on main (packages/client-runtime/src/operations/projects.ts, last changed in 6fd68f5c3).

Environment

Ubuntu 24.04 x64, headless, t3code.service as a systemd user service, accessed via T3 Connect. glab 1.119.0 (Homebrew), git_protocol: https. gitlab.com.