Sign up
View stargazersSign up

[Bug]: Adding a new project from Gitlab with Open in Finder results in no clone#12647

openedSep 19, 2026byJJoeIzzard

Before submitting

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

Area

apps/desktop

Steps to reproduce

  1. Select existing repo from Gitlab
  2. Use the 'Open In Finder' button
  3. Select the location for the project
  4. Click Finders 'Open' button

Expected behavior

When clicking 'Open' the repo should be cloned the same as in app directory selection.

Actual behavior

The project will be added to T3 Code, but it won't clone the repo.

Impact

Minor bug or occasional failure

Version or commit

0.0.43-nightly.20260919.1978

Environment

MacOS Tahoe 26.6.2

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

No response

Workaround

Delete the project and re-add using T3 Codes in app directory selection

JJulius MarmingeSep 19, 2026

Thanks for the clear repro and workaround.

This looks like a real desktop bug, and it is not GitLab-specific. The same path would skip the clone for GitHub, Bitbucket, Forgejo, Azure DevOps, or a pasted Git URL.

What happens

On the clone destination step, in-app folder selection plus Clone / Enter calls submitAddProjectCloneFlow, which starts the clone (and creates the project as part of that). Open in Finder uses a different handler that only adds the chosen folder as a project (createWorkspaceRootIfMissing: true) and never starts cloneRepository / startProjectClone.

That matches what you saw: the project appears, the repo is not cloned. The Finder dialog itself is fine; the picked path is just consumed as “add project” instead of “clone here.”

Relevant code:

  • apps/web/src/components/CommandPalette.tsx — handleOpenProjectFromFileManager always adds; clone submit is only on Enter and the Clone button
  • packages/client-runtime/src/operations/projects.ts — in-app browse pins the destination as <chosen folder>/<repo>

Workaround (as you found): delete the empty project and choose the destination with the in-app picker, then Clone/Enter.

Fix direction: when the palette is on the clone confirm step, Finder Open should resolve the picked folder the same way in-app browse does (getCloneDestinationBrowsePath / getCloneDestinationPath, so a folder already named after the repo does not become repo/repo) and then call submitAddProjectCloneFlow. The WSL UNC branch of that handler needs the same treatment.

Accepting this. No logs needed unless a fix still fails after that change.

JJulius Marminge21d ago

Existing fix: #22226 explicitly addresses this report by submitting native folder selections through the clone flow. It is still open; no duplicate PR was created.

Checked current main b5a226e49c: the picker handler still adds the selected folder directly. Independent runtime reproduction on Linux was inconclusive: vp run dev started, but browser navigation timed out and the subsequent snapshot disconnected. The native macOS Finder flow remains unverified here. The existing PR also has a WSL picker review comment awaiting assessment. Leaving this issue open for that fix.