[teamleaderleo]

Leo, 2026-10-31, on an agent chat tab with a salmon underline and an orange dot beside it: "WHY DOES THIS HAVE A LINE AND COLOR?????? / WHERE IS ORANGE COMING FROM?????????? AN ORANGE DOT????"

Leo-ask: ask-88148faefe

What it was

The tab was in an unnamed tab group. Such a group's chip is a bare colour dot (TabGroupChipCell), and the group band draws the underline (TabGroupBandCell). Nobody picked the colour: tabGroup.create (the tab menu's New Tab Group, the palette and the CLI through the app) gave any group created without a colour the next palette colour (TabGroupOrdering.nextColor, from cx-wqn5).

Change

• A tab group created without a colour gets grey, which is the daemon's own default for create-tab-group. No palette colour shows up that nobody chose.
• A colour the caller names (--color, the group editor) still shows as before.
• The chip, the underline geometry and the grouping itself are unchanged. They are just neutral now.
• Out of scope: screen groups and sidebar workspace groups keep their colour walk, since Leo pointed only at the tab.

Tests

TabSelectionActionsTests.thePaletteGroupsTheSameSelectedTabs now also asserts that the new group's colour is grey. The app compile check runs on the fleet.

Small change (one-line default plus a test assertion).

Agent session: agent session

🤖 Generated with Claude Code

---

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

---

Summary by cubic

Tab groups created without a chosen color now get grey instead of the next palette color, so no unintended orange dot and underline appear when nobody picked a color. A color the caller names (via --color or the group editor) still shows as before.

^{Written for commit 95345a1. Summary will update on new commits.}

[github-actions]

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

Review 95345a1: 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=pr32156 -f ref=lane/tab-group-neutral-default -f platform=macos -f backend_mode=local

Default changes

This pull request changes 1 default at 95345a11fa3c (what everyone gets without configuring anything):

• tunable-source.CmuxNextApp/Handlers/TabGroupHandlers.swift:bindMembership: "79da334ffa47992277e8f545965d8b1b96ada8ab8af76ac2b98fdc0ddd3c300b" -> "f94e2b533dc59e00c678c6c9f53ca2347b8395e156cd5386a3d65953bbde731d"

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

Merge receipt: merged as 4816325eaf64 with these defaults changed, signed off by review (subagent opus-5.5 medium).

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

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4143649268801 (d887a9ec1b)
• cmux NEXT nightly 1.0.0-nightly.4143770410701 (45490d20ae)
• cmux NEXT nightly 1.0.0-nightly.4143839654801 (3a5b96c9c8)
• cmux NEXT nightly 1.0.0-nightly.4143934830301 (1e057e0cf1)
• cmux NEXT nightly 1.0.0-nightly.4144017965101 (18e36f549a)

[teamleaderleo]

Review (subagent opus-5.5 medium): SHIP at 95345a1

Checked that the imports are still used and that nothing is newly unused. The test's types (PaneModel.tabGroups, TabGroupModel.color) match. No existing test expects a palette colour from tabGroup.create. The daemon accepts and stores "grey". Follow-ups: screen groups still use nextColor.

[lawrencecchen]

This PR made the feat-cmux-next tip red on the arch ratchet: [app_lines] CmuxNextApp Swift lines: +1 (the new comment in TabGroupHandlers.swift is 1 line longer than the old comment and expression). #32165 makes the comment 2 lines; the rule and the reason stay, the code does not change.