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

Activity

1. JoeIzzard

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 19, 2026
2. juliusmarminge commented on Sep 19, 2026

   

   juliusmarminge

   on Sep 19, 2026

   Member

   More actions

   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.
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 19, 2026
4. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   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.
5. juliusmarminge

   closed this as completedin #22226on Nov 11, 2026