[teamleaderleo]

Leo, 2026-11-01:

a lot of these asks or whatever when you guys create them it looks really odd when they pop up into some existing group on the sidebar as a workspace and then go to wherever they're supposed to go to

i feel like the animation should be less jarring/sometimes they dont need animations

What was wrong

agent.openSessionWorkspace (what acpmux new --group, cmux agent open --group and the asks reconciler's sessions go through) registered two placements for one new workspace:

1. Cmd-N's workspaces.newPlacement slot. Under the default top, that is the top of the window's current group.
2. Then a join into the named group.

So the row first stood in whatever group the window was showing, then moved across on the sidebar's .move spring to its real group. That is the jump Leo saw.

A second, smaller late-metadata move: the caller's lineage parent (AgentSessionParents) was recorded only after the chat tab opened. That let the row list at top level and then nest under its caller a moment later (sidebar.lineageNesting is on by default).

Fix

• With a group named, the group join is the row's only placement (byDefault is nil). Without a group, nothing changes: cmux NEXT: a session an agent opens without --group joins its parent's sidebar group #29889's below-the-parent slot, else the setting.
• The lineage parent is recorded before the create, so the row nests from its first frame.
• New-row motion is unchanged. sidebar.insertMotion is already snap by default: rows below land in place and the new row fades in at its slot. That is the quiet appearance the ask wants. The travel came only from the second placement, which is now gone.

Design spec: leo-workspace design/sidebar.md gets the rule "Never show a new workspace row anywhere but its final place" (PR linked below).

Prior art read: #29889 (an agent's spawn without --group joins its parent's group; kept as is) and #28730 (group-name matching; unchanged).

Test

AgentSessionGroupDirectPlacementTests: a window showing a workspace in group "current" while an agent opens a session with group: "lanes". The test hooks the production join and records where the row stands when the join runs. On base, the row is already in "current" at that point.

• Red at dc0c6b2: cmux-ci run --class light --script scripts/ci/package-test-lane.sh --arg=suite --arg=Packages/macOS/CmuxNext --arg=AgentSessionGroupDirectPlacementTests: failed on the fleet (step df9231c4520cd635f681f80d): Expectation failed: (seen.groupBeforeJoin → "g-current") != (.some(current.rawValue) → "g-current")
• Green at the head, with AgentSessionGroupPlacementTests, AgentSessionParentGroupTests and AgentSessionGroupJoinTests at c98a891: all 4 suites passed on the fleet (step c392c7eff84d691bd963733a)

Observed / Not run

• Observed: the fleet suite runs above. Review: SHIP at c98a891 (receipt comment). Follow-up: cmux NEXT: a new sidebar group made by an agent's --group open takes newPlacement's index #30603.
• Not run: a nightly with an agent-created session (that is the lane's stop condition, after landing). No capture: Mac-only timing change with no new look.

Risk: low/normal. One handler's placement registration; a contained sidebar behavior fix.

Changelog

• Fixed: a session an agent opens in a sidebar group appears straight in that group, instead of first showing in the current group and then moving.

Agent session: agent session

🤖 Generated with Claude Code

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review c98a891: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr30583 -f ref=lane/sidebar-agent-insert-group -f platform=macos -f backend_mode=local

Default changes

This pull request changes 2 defaults at c98a891c57e5 (what everyone gets without configuring anything):

• tunable-source.CmuxNextApp/Handlers/AgentSessionWorkspace.swift:expectPlacement: (none) -> "bb452ef139872ed0b9d4cff7087cc92d6a2c74366caa52ccfcc4aee5152cbc62"
• tunable-source.CmuxNextApp/Handlers/AgentSessionWorkspace.swift:open#: "92f535248a626ef129b7b263d0fa38e79d53a5511e21d2be35ef806c36be5aff" -> "4b4de17b83583f5f83bf1b84950095debd45c2ddeeb80fb4f0d0f363447f18ad"

Signed off on this commit by review (subagent claude-opus-5-5 medium).

Merge receipt: merged as 8d467555b989 with these defaults changed, signed off by review (subagent claude-opus-5-5 medium).

Regenerate the snapshot with python3 scripts/ci/defaults_guard.py snapshot.

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4130052256501 (28aa638015)

[teamleaderleo]

Review (subagent claude-opus-5-5 medium): SHIP at c98a891

Every case traced (existing group, the current group as the target, a remote daemon, the newGroup path, top with a group, the all-nil bail-out) lands the row in the same final place as on base, minus the hop through the current group. Moving recordParent ahead of the create is harmless: the session already exists, the daemon's lineage still wins, and the 4,096-entry cap applies. On base the test sees the row in "g-current" before the join.

Follow-ups:

• [follow-up] --top --group <new group>, and a new group from a grouped open in general, now forms at the daemon's spot instead of Cmd-N's slot. Pass NewWorkspacePlacements.newGroupIndex (or 0 for top) through newGroup. Filed as an issue.

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="Packages/macOS/CmuxNext/Sources/CmuxNextApp/Handlers/AgentSessionWorkspace.swift">

<violation number="1" location="Packages/macOS/CmuxNext/Sources/CmuxNextApp/Handlers/AgentSessionWorkspace.swift:106">
P2: `recordParent` persists the child’s lineage before workspace creation succeeds, but the failure paths never roll it back. A failed or refused creation can therefore leave a stale persistent parent that incorrectly nests a later workspace for the same session; add rollback for the early record on every creation failure.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: recordParent persists the child’s lineage before workspace creation succeeds, but the failure paths never roll it back. A failed or refused creation can therefore leave a stale persistent parent that incorrectly nests a later workspace for the same session; add rollback for the early record on every creation failure.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At Packages/macOS/CmuxNext/Sources/CmuxNextApp/Handlers/AgentSessionWorkspace.swift, line 106:

<comment>`recordParent` persists the child’s lineage before workspace creation succeeds, but the failure paths never roll it back. A failed or refused creation can therefore leave a stale persistent parent that incorrectly nests a later workspace for the same session; add rollback for the early record on every creation failure.</comment>

<file context>
@@ -100,18 +100,11 @@ enum AgentSessionWorkspace {
+        expectPlacement(key.rawValue, group: group, top: top, parent: parent, windows: windows)
+        // The lineage parent before the row lists, so the row nests under its caller from its first frame, never moves
+        // under it once the tab has opened.
+        AgentSessionWorkspace.recordParent(parent, of: AgentSessionParents.identity(host: targetHost, session: session),
+                                             in: SidebarSessionTreeFeed.shared.recordedParents)
         return Task { @MainActor in
</file context>

[lawrencecchen]

Tip note: this PR and #30565 together added +15 CmuxNextApp Swift lines, so the arch ratchet's app_lines row went red at feat tip 61ad0ed. It went green again at 6bd0a43 with no action, because #30610 moved 16 lines out of CmuxNextApp. Nothing to do here. Next time, put new code in its owning package (plans/cmux-next/code-quality.md SW14), not in CmuxNextApp.