sometimes the new worktrees created are not shown in the left pan area

[vidyasagarr7]

Where did this happen?

Desktop app (macOS)

Version

1.24.2

What happened?

Created a new worktree. It shows up in workfpsaces, but doesnt show under projects in the left pan area.

Steps to reproduce

asdf

Logs, screenshots, or recordings

No response

[github-actions]

Summary

A newly created worktree shows up in the Workspaces list but never appears under its project in the left pane. Those two surfaces read from different sources: the Workspaces page derives rows straight from what the hosts serve (useAccessibleV2Workspaces.ts:380-422 — "a host-served row is its own proof of existence"), while the sidebar renders a workspace only through its project group, and that group exists only if there is a local v2SidebarProjects placement row for the project. If that placement row is missing, the sidebar silently drops the workspace — and the in-app create path never creates one.

Affected code

• apps/desktop/src/renderer/routes/_authenticated/_dashboard/components/DashboardSidebar/hooks/useDashboardSidebarData/buildDashboardSidebarProjects.ts:252-257 — the drop:

  const project = projectsById.get(workspace.projectId);
  if (!project) continue;   // ← workspace vanishes from the sidebar entirely

  projectsById is seeded only from sidebarProjects (line 223), which comes from the v2SidebarProjects ⋈ useHostProjects join in useDashboardSidebarData.ts:210-233.
• apps/desktop/src/renderer/stores/workspace-creates/writeWorkspacePaneLayout.ts:60-74 — the create path inserts the v2WorkspaceLocalState row for the new workspace and never touches v2SidebarProjects.
• apps/desktop/src/renderer/routes/_authenticated/hooks/useDashboardSidebarState/useDashboardSidebarState.ts:205-215 — ensureWorkspaceInSidebar does call ensureSidebarProjectRecord first, but nothing on the create path calls it (useSubmitWorkspace.ts:207, useQuickCreateWorkspace.ts:38 both go straight to submit()).
• apps/desktop/src/renderer/routes/_authenticated/components/AgentHooks/hooks/usePlaceLocalWorktreesInSidebar/usePlaceLocalWorktreesInSidebar.ts:53-65 + selectWorktreesToPlace.ts:27 — the reconciler that would heal this treats "has a v2WorkspaceLocalState row" as "already placed" and skips it, so the workspace stays invisible across restarts.

Suspected root cause

An in-app worktree create writes workspace placement but not project placement. Whenever the project has no v2SidebarProjects row at that moment, the workspace (and its whole project group) is dropped by buildDashboardSidebarProjects, permanently — the reconciler won't re-place a workspace that already has a row. Ways to end up with a project that has no placement row while still being creatable:

1. The project was removed from the sidebar earlier. removeProjectFromSidebarState (sidebarMutations.ts:87-156) deletes the v2SidebarProjects row by design, but the new-workspace modal's project picker lists all host projects (DashboardNewWorkspaceModalContent.tsx:34), not sidebar projects, so you can still create into it.
2. useQuickCreateWorkspace falls back to lastProjectId / hostProjects[0]?.id (useQuickCreateWorkspace.ts:26-31) — again all host projects.
3. The placement collections are localStorage-backed, so a quota eviction / profile reset can drop project rows while host workspaces survive.

That matches "sometimes": it only bites when the project's placement row happens to be absent, which is invisible from the UI.

Secondary possibilities I could not rule out from the code, worth checking against the reporter's exact case:

• Worktrees created on a remote host / another device are never auto-placed at all — usePlaceLocalWorktreesInSidebar.ts:34 filters hostId === machineId, so a CLI-created worktree on another machine shows in Workspaces and never in the sidebar.
• The project group or its group/section is collapsed (v2SidebarProjects.isCollapsed); ensureSidebarProjectRecord returns early on an existing row and never expands it, so a new worktree can land inside a collapsed group. Same for the whole Workspaces list being collapsed (DashboardSidebar.tsx:310).

A quick discriminator for the reporter: on the Workspaces page, right-click the missing worktree → Add to sidebar (V2WorkspaceContextMenu.tsx:62-64). That calls ensureWorkspaceInSidebar, which creates the project row. If the worktree (and its project) appears immediately, the missing-v2SidebarProjects-row cause above is confirmed.

Reproduction

Manual:

1. In the left pane, right-click a project → remove it from the sidebar.
2. Open the new-workspace modal (or quick-create), pick that same project, create a worktree.
3. The workspace opens and is listed on the Workspaces page; the left pane shows no project group and no row for it. Relaunching the app does not fix it.

Unit-level, next to the existing cases in buildDashboardSidebarProjects.test.ts (helpers already defined there):

it("drops a workspace whose project has no sidebar placement row", () => {
  const groups = buildDashboardSidebarProjects({
    sidebarProjects: [],                    // no v2SidebarProjects row
    sidebarSections: [],
    visibleSidebarWorkspaces: [
      makeWorkspace({ id: "new-worktree", projectId: "project-1" }),
    ],
    machineId: MACHINE_ID,
    pullRequestsByWorkspaceId: new Map(),
  });

  expect(groups).toEqual([]); // ← the reported symptom
});

Paired with a writeWorkspacePaneLayout test asserting that after a create into project-1, collections.v2SidebarProjects.get("project-1") is still undefined while v2WorkspaceLocalState.get(workspaceId) exists — that's the gap.

Fix direction

Make the create path ensure project placement the same way ensureWorkspaceInSidebar does: call ensureSidebarProjectRecord(collections, projectId) for non-null projectId in writeWorkspacePaneLayout (or in useWorkspaceCreates.submit before the first writeWorkspacePaneLayout call). That keeps the "explicit creation surfaces in the sidebar" invariant the reconciler already documents, and doesn't disturb the "removed stays removed" invariant, since removal tombstones existing worktrees (isHidden) and only a new create would resurrect the group — which is what the user just asked for.

Worth considering alongside it: a self-heal in usePlaceLocalWorktreesInSidebar for rows that are visible (not hidden) but whose sidebarState.projectId has no v2SidebarProjects row, so existing broken profiles recover without the user finding "Add to sidebar"; and unc追ollapsing is a separate question if the collapsed-group hypothesis turns out to be the reporter's actual case.

[Kitenite]

Thanks for the report @vidyasagarr7! Reproduced it. Your worktree still exists and is fine, it is only the left pane that drops it: the sidebar renders a workspace through its project group, and if that project's local sidebar entry is missing, the whole group and its worktrees disappear from the left pane while the Workspaces page still lists them. Restarting does not bring it back. A fix is on the way that also repairs profiles already in this state.

To get it back right now: open the Workspaces page, right-click the missing worktree and choose "Pin to Sidebar". Let us know if it reappears immediately, that confirms this is your case.