#24162 cmux-next: agent open --group joins the existing same-named group; a re-homed lane reuses its row

Summary

Leo, 2026-10-22: "you also just kept adding them to same-named groups...? this doenst seem rightr"

After the big-red lane re-home, Leo's sidebar had 9 extra "GUI push · lanes" groups, one lane each and some empty. Four lanes (prompt-queue-edit, pane-motion, pr-cards, deeplink-message) each had a second row next to the old one.

agent.openSessionWorkspace (cmux agent open --group, which acpmux new --group runs) only tried the first personal group with the requested name. When that group couldn't hold the new row (a different machine row's group, or a group that exists only on the sidebar document), it made a new group with the same name, and did that again for every lane.

• Joining a group: it now tries every listed group with that name, in any section and either organization, and joins the first that SidebarEdits.canMove allows. It makes a new group only when none can hold the row.
• Re-homed lane: when the requested name already has a row in that group (a lane re-homed to another machine gets a new session, so a new workspace key), the new session's chat opens as a tab of that row and is selected there. The launcher's key is the tab's creation key, so running the launcher again returns the same tab.

Testing

• 3ab027ee4bf adds AgentSessionGroupJoinTests first (red: it doesn't compile, because group(named:accepting:in:) and predecessor(named:inGroup:in:) don't exist yet).
• bae6161 is the fix. Fleet cmux-ci compile-check --app passed on that head. The fleet package-test-lane run of AgentSessionGroupJoinTests and NewWorkspaceInGroupTests is in the comments.

Observed / Not run

• Not run: a live re-home in the app. The new tab inside the reused row is checked by the compile and code reading, not dogfooded.
• The extra groups and rows already on Leo's sidebar were cleaned up by hand. This PR stops new ones.

No capture: the change is which existing group a new row joins; nothing on screen is drawn differently.

Changelog

• Fixed: cmux agent open --group joins the existing group of that name instead of making another, and a re-homed agent's chat opens in its existing sidebar row.

🤖 Generated with Claude Code
Agent session: huge-blue

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes cmux agent open --group creating duplicate same-named sidebar groups and duplicate rows for re-homed lanes.

agent.openSessionWorkspace only tried the first personal group with the requested name. When that group couldn't hold the workspace (another machine's row, or a group existing only on the sidebar document), it created a new group of the same name — repeatedly, leaving nine "GUI push · lanes" groups. It now tries every listed group with that name, in any section and either organization, and joins the first that SidebarEdits.canMove allows. A new group is made only when none can hold the row.

A re-homed lane's new session gets a new workspace key, so it used to appear as a second row next to its predecessor's. Now, when the requested name already has a row in the group, the chat opens as a tab of that row and is selected there. The predecessor row is looked up in every window's sidebar, since it can be in any of them. The launcher's key becomes the tab's creation key, so running the launcher again returns the same tab. Only this Mac's rows are candidate predecessors, since the chat opens on this Mac's daemon.

Testing

• Adds AgentSessionGroupJoinTests, covering group selection across sections and organizations, predecessor-row lookup, and that another machine's row is never a predecessor; the live app re-home path was not dogfooded.