[nwparker]

Fixes #9497.

What was wrong

Cmd/Ctrl+1–9 jumps to the Nth workspace card. The handler asks getVisibleWorktreeIds() for the order.

While the sidebar is open, WorktreeList publishes the exact list of IDs it rendered, so the numbering matches the cards. While the sidebar is closed, WorktreeList is unmounted and the function fell back to a flat, membership-ordered list — a filtered-and-sorted set of workspace IDs that never went through the sidebar's row pipeline.

That flat list ignores everything the pipeline does to arrange cards:

• main-worktree hoisting — each repo's main workspace is anchored to the top of its group
• grouping by repo/project/status, and project group ordering
• pinning — pinned workspaces are lifted into their own section (policy-dependent)
• collapsed groups — members render no card at all, so they own no number
• host sections — with a host filter on, workspaces are re-bucketed per host
• folder workspaces — these only ever enter via folder-workspace rows, so the flat list omitted them entirely

So closing the sidebar silently renumbered the workspaces. The reporter's "Cmd+1 selects the second workspace" is exactly the main-worktree hoisting case: the flat list kept membership order, while the sidebar had hoisted main to position 1.

ELI5

The sidebar is a list of doors, numbered top to bottom. When the sidebar was open, door #1 was the one your eyes landed on first. When you closed the sidebar, the app stopped looking at the doors and instead read an unsorted inventory sheet — same doors, different order. Pressing "1" opened whatever door happened to be first on the sheet, which usually wasn't the door you'd counted as first.

Now, with the sidebar closed, the app arranges the doors the same way the sidebar would have before counting — so "1" always means the same door.

The fix

New module rendered-sidebar-worktree-order.ts replays the sidebar's own pipeline against a store snapshot:

buildRows(...) → addHostSectionRows(...) → getRenderedWorktreesInSidebarOrder(...)

This reuses the ordering logic rather than re-deriving it, so the two paths can't drift apart later. Its arguments mirror WorktreeList's real call sites one-for-one.

Two deliberate simplifications, both proven not to affect order:

• The four placeholder/imported/inbox/pending inputs are passed empty — they only ever emit their own row types, never item or folder-workspace rows (the only two the order reads).
• hostLabelById is undefined — it feeds display-only host context labels, never row order.

addHostSectionRows is skipped when there's no host filter, where it is a pass-through — so a keystroke doesn't build the whole host registry for nothing.

Second, separate bug fixed

The published-order cache was guarded by if (_cachedVisibleIds.length > 0). An empty array is ambiguous: it means both "unmounted" and "mounted, but every card is collapsed or filtered away". In the second case the guard fell through to the flat list, so a mounted sidebar showing zero cards could still jump to a workspace with no visible card. The published order is now string[] | null, where null means unmounted and [] is a real, authoritative empty order.

Fix proof

Both the "before" and "after" closed-sidebar orders in this image are produced by running the real code paths against a seeded store — they are not hand-authored mockups. Source: evidence/9497-shortcut-order.

9 new tests drive the real getVisibleWorktreeIds() entry point against a seeded store — not the internal helper — so they cover the exact path the Cmd+N handler takes.

Mutation-tested (the tests fail when the fix is removed, so they aren't tautological):

Mutation	Result
Restore the old flat fallback	9 of 9 fail. Headline case returns ['wt-feature','wt-main'] where the sidebar renders ['wt-main','wt-feature'] — the reported symptom, reproduced exactly.
Restore the length > 0 guard	Exactly 1 fails — the explicitly-empty-order test, isolating the second bug.
Both restored (i.e. main)	Baseline green.

Coverage: main-worktree hoisting, collapsed groups, folder workspaces, explicit host filtering, both pinned-display policies, smart + comparator sort modes, and published-vs-recomputed precedence.

Proof of no regressions

• 1674/1674 tests pass across src/renderer/src/components/sidebar/ + useIpcEvents.test.ts (184 files)
• tsc -p config/tsconfig.tc.web.json --noEmit → exit 0
• oxlint src/renderer/src/components/sidebar/ → exit 0
• useIpcEvents.test.ts 81/81 still green — its 15 vi.doMock('@/components/sidebar/visible-worktrees', …) sites still intercept, because the public entry points deliberately stayed in that module (the new module is a leaf it calls, not a replacement)
• No max-lines disable added; visible-worktrees.ts stays within its 300-line budget

Performance

getVisibleWorktreeIds() now runs the row pipeline. Its only production caller is the onJumpToWorktreeIndex IPC handler — once per keystroke, not in any render path or high-frequency event. Measured on this machine:

Workspaces	Cost per call
50	0.12 ms
500	0.78 ms

Scaling is linear (10× the workspaces → 10.3× the time), so there's no hidden quadratic. Sub-millisecond at 500 workspaces is far inside a 16 ms frame.

Trade-offs

• The closed-sidebar path does more work than before (a full row-pipeline pass instead of a flat map). Quantified above: ~0.1–0.8 ms, once per keypress. Correctness is worth it, and the alternative — caching the last rendered order — cannot number a workspace created while the sidebar was closed, since a retained cache can only ever remove IDs it already had. There is a test for exactly that case.
• Ordering rules now have one owner. If someone adds a new row type that should be numbered, they must add it to getRenderedWorktreesInSidebarOrder — but that was already true for the sidebar itself, so this removes a divergence rather than adding an obligation.
• No user-visible regression. The numbering only changes where it was previously wrong (sidebar closed); the open-sidebar path is untouched and still uses the published order verbatim.

Cross-platform

Ordering logic only — no platform branches added or touched. The Cmd-vs-Ctrl decision happens upstream in shared/window-shortcut-policy.ts, which is already platform-aware and unmodified. Nothing here is macOS-specific despite the issue's os:macos label; Linux/Windows users were hitting the same wrong ordering via Ctrl+N.

Relationship to #9548

@OnlyYu1996 opened #9548 for this issue first, and their diagnosis of the open-vs-closed split was correct — credit to them for finding it. That PR prunes the retained cache on unmount. I went a different way because pruning can only ever remove stale IDs: a workspace created while the sidebar is closed still gets no number, and the ordering rules stay duplicated in two places. This PR derives the order from the sidebar's own pipeline instead, which covers both. Happy to close either one in favor of the other.

Review loop

Adversarially reviewed by two independent models (GPT-5.6-Sol and Fable). 4 rounds to clean.

Round	Focus	Verdict
1	Broad correctness + tests	Not clean. Produced a stronger test file driving the real getVisibleWorktreeIds() entry point (adopted after I verified it), but it also asserted a fabricated host-section order — corrected against host-section-rows.ts:265-270, which orders by the host registry, not by the filter argument.
2	Argument fidelity + sentinel lifecycle	Inconclusive (reviewers timed out). I did this pass myself and found the one real fidelity risk: effectiveCollapsedGroups vs state.collapsedGroups. Resolved — the divergence needs an open agent-send popover, which needs a mounted sidebar, which publishes its order and never reaches this path. Pinned by a test.
3	Row-order fidelity; sentinel staleness	CLEAN ×2. No argument mismatch affecting order/membership. StrictMode setup→cleanup→setup ends correct; useReusedArrayIdentity only reuses identity when every element is strictly equal, so a content change always re-publishes.
4	Dedupe occurrence; folder-workspace id namespace; false test assertions	CLEAN. getRenderedWorktreesInSidebarOrder already emits one row per workspace at its preferred position, so the trailing new Set has no duplicate to mis-choose; folder-workspace keys resolve end-to-end via getKnownWorktreeById.

Two review comments were acted on rather than argued: the module JSDoc was trimmed from 16 lines to 7 per AGENTS.md's concise-comment rule, and a needsHostSections note that misstated the cost was corrected.

An independent reviewer also statically checked the headline test against the pre-fix commit c06bf64b48 and reproduced the failure — pre-fix ordering yields ['wt-feature','wt-main'] where the test requires ['wt-main','wt-feature'].

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5600c13b-3c11-4912-abc4-51d9c0183efc

📥 Commits

Reviewing files that changed from the base of the PR and between b3964df94e2681365e38dddc33575ac936046a06 and 6b2d2e7.

📒 Files selected for processing (5)

• src/renderer/src/components/sidebar/WorktreeList.tsx
• src/renderer/src/components/sidebar/rendered-sidebar-worktree-order.test.ts
• src/renderer/src/components/sidebar/rendered-sidebar-worktree-order.ts
• src/renderer/src/components/sidebar/visible-worktrees.ts
• src/renderer/src/components/sidebar/worktree-list-host-filtering.ts

🚧 Files skipped from review as they are similar to previous changes (4)

• src/renderer/src/components/sidebar/rendered-sidebar-worktree-order.ts
• src/renderer/src/components/sidebar/rendered-sidebar-worktree-order.test.ts
• src/renderer/src/components/sidebar/worktree-list-host-filtering.ts
• src/renderer/src/components/sidebar/WorktreeList.tsx

---

📝 Walkthrough

Walkthrough

The sidebar now centralizes execution-host visibility filtering for project groups and folder workspaces. Closed-sidebar Cmd+1–9 ordering is computed through the rendered sidebar row pipeline, including host sections, pinned workspaces, collapsed groups, folder workspaces, and sorting behavior. Published worktree IDs are nullable so unmounted sidebars trigger recomputation, while explicitly published empty orders remain authoritative. New tests cover these ordering and host-filtering cases.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description covers the bug, fix, tests, and review, but it does not follow the repository's required template sections.	Add the required sections: Summary, Screenshots, Testing checklist, AI Review Report, Security Audit, and Notes.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: closed-sidebar Cmd/Ctrl+1-9 now matches rendered card order.
Linked Issues check	✅ Passed	The changes address #9497 by preserving the same visible workspace order whether the sidebar is open or closed.
Out of Scope Changes check	✅ Passed	The added helpers, helper tests, and visibility-cache changes all support the closed-sidebar ordering fix and are in scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

src/renderer/src/components/sidebar/worktree-list-host-filtering.ts (1)

2-21: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Migrate the remaining inline duplicate in computeVisibleWorktreeIds to this helper.

visible-worktrees.ts's computeVisibleWorktreeIds still inlines the identical visibleWorkspaceHostIds ?? (workspaceHostScope === ALL_EXECUTION_HOSTS_SCOPE ? null : [workspaceHostScope]) → new Set(...) derivation instead of calling getVisibleSidebarHostIdSet. This is exactly the class of drift this PR's own rationale warns about ("the sidebar render path and the Cmd+1–9 order must apply the same host filtering, or the numbering drifts"). Since computeVisibleWorktreeIds also feeds the closed-sidebar recompute path, a future change to this helper's semantics could silently diverge from that inline copy.

♻️ Suggested consolidation in visible-worktrees.ts

// computeVisibleWorktreeIds, inside visible-worktrees.ts
const visibleHostIdSet = getVisibleSidebarHostIdSet(
  opts.visibleWorkspaceHostIds,
  opts.workspaceHostScope
)
if (visibleHostIdSet) {
  all = all.filter((w) => {
    const repo = opts.repoMap.get(w.repoId)
    if (!repo) return false
    const hostId = getWorktreeExecutionHostId(w, repo, opts.defaultHostId)
    return visibleHostIdSet.has(hostId)
  })
}

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4266fd6a-139d-4077-8810-f00d0fbbebee

📥 Commits

Reviewing files that changed from the base of the PR and between c67aadb and d1bf65c.

📒 Files selected for processing (5)

• src/renderer/src/components/sidebar/WorktreeList.tsx
• src/renderer/src/components/sidebar/rendered-sidebar-worktree-order.test.ts
• src/renderer/src/components/sidebar/rendered-sidebar-worktree-order.ts
• src/renderer/src/components/sidebar/visible-worktrees.ts
• src/renderer/src/components/sidebar/worktree-list-host-filtering.ts

[nwparker]

Rebased onto current main (07671d4a06) — no conflicts.

Two sidebar commits landed since this branch was cut (4ff2f51782 shared agent-orchestration index, 28dfc13654 CLI-created workspace filtering), so I re-validated against them rather than merging stale:

• 1689/1689 tests pass across src/renderer/src/components/sidebar/ + useIpcEvents.test.ts (185 files — up from 1674/184, the new tests are green too)
• tsc -p config/tsconfig.tc.web.json --noEmit → exit 0
• oxlint src/renderer/src/components/sidebar/ → exit 0
• The 9 new tests still pass and the mutation proof still holds.

[nwparker]

CI note: verify red on the first post-rebase run was a Docker Hub outage, not this change

Run 30193514168 failed in Verify Git binary compatibility matrix:

Error: Command failed: docker run --rm --network=none ... alpine/git:v2.49.1 -c safe.directory=/repo --version
Unable to find image 'alpine/git:v2.49.1' locally
docker: Error response from daemon: Head "https://registry-1.docker.io/v2/alpine/git/manifests/v2.49.1":
  received unexpected HTTP status: 502 Bad Gateway

The suite never executed — 4 tests | 4 skipped, failing at image pull. The other two legs of the same matrix passed on this exact commit: source-built Git 2.25.5 → 4/4, alpine/git:edge-2.38.1 → 4/4.

This PR touches only src/renderer/src/components/sidebar/*; it has no Git-binary surface. Re-running the failed job.

[nwparker]

Follow-up: the second verify failure is a pre-existing break on main, also not this PR

The re-run got past the Docker outage and surfaced a different, real failure:

FAIL  src/main/persistence.test.ts > Store > derives fresh default profiles without branch
AssertionError: expected [ 'status', 'unread', 'issue', …(7) ] to deeply equal [ 'status', 'unread', 'issue', …(6) ]
    "automation",
+   "cli",
    "comment",

I reproduced it on pristine origin/main (54e22402bc) with none of this PR's code present — 1 failed | 416 passed. Cause: #10712 added 'cli' to DEFAULT_WORKTREE_CARD_PROPERTIES but left this one assertion listing the pre-'cli' array, so verify has been red on every commit since 28dfc13654.

This PR touches only src/renderer/src/components/sidebar/*; it is byte-identical to main in both src/main/persistence.test.ts and src/shared/worktree-card-properties.ts (git diff between the branches is empty for both).

Fix sent as #10722. Once that lands I'll rebase this PR onto it so verify here can go green on its own merits — I'd rather not merge onto a red main.

[nwparker]

Rebased onto the main repair — verify should now go green on its own merits

main is fixed (#10722, merged as 4326707285), so this PR is rebased onto it. New tip: 6b2d2e7503.

• Rebase was clean; all 5 commits replayed. git diff b3964df94e HEAD -- src/renderer/src/components/sidebar/ is empty — the reviewed code is byte-identical, only the base moved.
• Re-validated on the new base: 1689/1689 tests across 185 files (two consecutive runs), tsc exit 0, oxlint exit 0.

One transparency note: on the first post-rebase run, WorktreeCard.lineage.test.tsx and WorktreeCard.pinned-repo-icon.test.tsx hit 15000 ms timeouts. Both pass 5/5 standalone in 4.5 s and both passed on two subsequent full runs of the identical command — parallel-load flakiness in files this PR does not touch. I checked rather than assumed, because that same command had passed on pristine main.