[teamleaderleo]

Fixes the base red at webviews/test/agent-pane-queue-row-click.test.ts:477: "the model picker covers the row's actions, and a press there stays in the picker" expected {action: '[data-action="steer"]', inPicker: true} and got inPicker: false (base runs 41537873916 at b32e700, 41539691165, 41551051684, 41552172035, 41552636560).

Base-red-job: web / react-apps-check

Cause. No product regression: the picker still covers all three of the row's actions, and a press there still stays in the picker. A diagnostic run on this branch (run 41559053955) showed that, at the centre of Steer, the trash can and ⋯, elementFromPoint now hits the picker menu's own <div role="separator" class="ui-separator">. It sits in the gap between the menu's note row (y 621–649) and its next row (658), inside .acpmux-quick-menu (589–718), and the row's actions are at y ≈ 642–664. The test decided "in the picker" by regex-matching the hit's outerHTML for acpmux-quick or role="menu, and a bare separator matches neither. The picker's vertical layout moved and put the separator there. The first base red is at b32e700 (#30879, which changes no web code), so the shift came from the picker/composer layout changes merged just before it. I did not pin down one regressing PR: the REST quota for the host ran out before I could bisect earlier base runs. The model picker's own work (#30194 compact width, #31498 catalog harnesses, by teamleaderleo's lanes) is the likeliest source.

Fix. The test now asks the DOM, elementFromPoint(x, y)?.closest(".acpmux-quick-menu, [role=menu]"), instead of matching markup. A separator or the menu's padding over an action counts as the picker's, and anything from the queued row still fails. The second half of the test (a real press at ⋯ opens no row menu and sends no queue call) is unchanged.

Test. bun test test/agent-pane-queue-row-click.test.ts via cmux-ci (run 41559958396): 16 pass, 0 fail, chromium and webkit. vp fmt --check clean.

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 c18f9e3: 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=pr32783 -f ref=lane/web-base-red-queue-row-click -f platform=macos -f backend_mode=local

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4156852011001 (2f3ccfed7d)
• cmux NEXT nightly 1.0.0-nightly.4157013432001 (f338fc81fd)

[teamleaderleo]

Review (codex gpt-6-astra high, sweep, via the review router; full diff from merge base 4fbe098 to this head): SHIP at c18f9e3

No P1/P2 findings.

[teamleaderleo]

Review (subagent opus-5.5 medium): SHIP at c18f9e3

Visual verdict: unchanged by this diff (test-only).

Checked that the new closest(".acpmux-quick-menu, [role=menu]") assertion still fails if a queued-row action is hit (its ancestors are the row, .acpmux-composer-queue and the composer, none of which match). The row's own ⋯ popup is portalled and closed at that point, and the later rowMenu: 0 check would catch it anyway. The old outerHTML regex missed the picker's ui-separator; closest() fixes exactly that.

Follow-ups: [follow-up] hitAt's covered string goes unused in this loop; a small pickerAt(x, y) helper or a comment would make that clearer.