Repository navigation
Conversation
A project group is saved on the computer that created it, and a project row can join only its own computer's groups. The Move to group menus listed only group names, so with groups from several paired computers (or the same name on each) there was no way to tell them apart or to see why a move was refused. When the listed groups come from more than one computer, each item now shows that computer with the host label project headers use. Group headers stay unlabeled: in this window a group can hold rows from several computers, and a single machine label would claim it owns them all (stablyai#28250). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
[Low impact] The reviewed changes appear safe to merge. SummaryAdds computer labels to “Move to group” targets when groups span computers.
No new actionable issues were found in the changes since the previous review. No previous review threads were supplied. Reviews (2) · Last reviewed commit: "fix(sidebar): label same-id group copies..." · Reviewed by Greptile |
|
No actionable comments were generated in the recent review.
|
There was a problem hiding this comment.
Actionable comments posted: 1

Review info
-
Run configuration-
- Source mode: Auto
- Repository: Unavailable
- Branch: Unavailable
- File: No configuration file from this repository applied
- Commit: Unavailable
- Layers: Repository UI
- Review profile: CHILL
- Plan: Advanced
- Run ID:
3d7d7135-ba71-4fc0-8a4c-68f39c555dd5
Files selected for processing: 8-
src/renderer/src/components/sidebar/ProjectGroupMoveMenuItems.test.tsxsrc/renderer/src/components/sidebar/ProjectGroupMoveMenuItems.tsxsrc/renderer/src/components/sidebar/WorktreeContextMenuView.tsxsrc/renderer/src/components/sidebar/sidebar-host-options-context.tssrc/renderer/src/components/sidebar/worktree-list/rows/ProjectHeaderHostLabel.tsxsrc/renderer/src/components/sidebar/worktree-list/rows/project-header-host-context.tssrc/renderer/src/components/sidebar/worktree-list/rows/repo-header-project-actions.tsxsrc/renderer/src/components/sidebar/worktree-list/viewport/VirtualizedWorktreeViewport.tsx
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.
-
…ately Same-id copies of a group can sit on several computers (stablyai#30045). Keying the menu labels by group id kept only the last copy's computer, so both items read the same label, and the computer count could miss the copies entirely. Align the labels with the listed groups by position, and key the items by host and id so the copies are distinct React children. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ELI5
A project group lives on the computer that made it, and a project can only be put in a group on its own computer. With paired computers, Move to group lists everyone's groups, but only by name. So you can't tell whose group is whose, or why a move is refused. When the listed groups come from more than one computer, each item now shows its computer next to its name.
What Changed
This is a proposal for #35499; happy to adjust or drop it.
Before:
After:
text-xs.Nothing is hidden or disabled. Every group stays listed, and the store guard (
isProjectGroupJoinableFromCatalog) still refuses a cross-computer move and explains why. Sidebar group headers are unchanged.Mechanism:
project-header-host-context.ts:createHostContextResolver, which project headers already used: registry label,getHostContextLabelfallback, managed-orcad annotation, alias canonicalization.getProjectGroupHostContextsresolves each group's computer fromgetRepoExecutionHostId(group), which is whatgetProjectGroupHostIdand the store guard read. It returns them only when the groups span more than one canonical computer.getProjectHeaderHostContextskeeps its behavior and now uses the same resolver.ProjectGroupMoveMenuItems.tsx: the Move to group items for both the workspace card menu (WorktreeContextMenuView) and the project header menu (RepoHeaderProjectActionsMenu), which had the same inline list. It mounts only while the submenu is open.sidebar-host-options-context.ts: the viewport provides the sidebar's own host registry (hostOptions) to its rows. The menus read it instead of building host options again, so they add no read of the focused host (focus-read-ratchet) and no per-card store subscription. Workspace cards outside the sidebar (the Kanban drawer, the folder workspace panel) get no registry, so their menus list names only, as today. A bare runtime id is not a name to show.ProjectHeaderHostLabeltakes an optionalclassName. The menu passesmax-w-48, because the label'smax-w-1/2clipped "Local Mac" in a shrink-to-fit menu row.Why
Problem: a group is stored on one computer, and a row can join only its own computer's groups. The menu showed groups from every paired computer by name only. So picking the right group was guesswork, and a refused move came as a surprise. When two computers each had a group with the same name, the menu showed identical items, and one of them always refused.
Why this approach:
applyInheritedProjectGroups). A single machine label on the header would claim it owns them all. Keep project names short and show their machine #28250 rules that out for multi-machine projects and manual groups ("does not assign a singular owner to manual project groups"). In the menu the label describes the move target itself.Alternatives considered:
Linked Issue
Closes #35499
Visual Proof
Two Orca apps ran in the background on main
79dbada2c8and on this branch: a paired Electron client (Orca A) and a headless host (Orca B). Each added its own clone ofdemo-testwith the sameorigin. Orca A created "Group A" and Orca B created "Group B". The images are CDP screenshots of Orca A's hidden window, with the card menu of Orca A's workspace open on Move to group.79dbada2c8Text read from the rendered DOM:
Testing
I manually tested these changes locally
Automated tests added/updated, or explained why not below
New
ProjectGroupMoveMenuItems.test.tsx(real Radix menu): items name each group's computer when the groups come from two computers. They list only names when every group is on one computer, and outside the sidebar.project-header-host-context.test.tspasses unchanged, including "does not assign a singular owner to manual project groups".pnpm check:changed --maxWorkers=2(format, lint, typecheck, affected tests, ratchets includingfocus-read-ratchet: 22 checks) passes.pnpm test src/renderer/src/components/sidebar src/shared/sidebar-list: 3365 passed, 1 skipped (386 files).npx electron-vite build --mode e2esucceeded on both commits for the E2E above; I did not run the fullpnpm buildlocally.Platforms: macOS (unit tests and the two-app background E2E above). The change is renderer-only with no platform branches.
AI Disclosure
Implemented with Claude Code (Claude Opus 5.5). Reviewed by GPT-6.1 Sol (xhigh reasoning).
ProjectHeaderHostLabel.Review
Agent skill upstream boundary
Notes
Ensure no issues in: Security, Cross-platform support (Linux, Windows, Mac), Remote SSH, Mobile, general backwards compatibility, performance
ssh:host through the same resolver, with aliases canonicalized as for projects.mobile/src/host-screen). No phone change.repo-header-project-actions.tsx, to act on the row that placed the project). Whichever lands second needs a small rebase there.Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)🤖 Generated with Claude Code