Best possible solution:

Keep the shared app-level pairing dialog, but publish setup-code state as soon as device.pair.setupCode resolves and refresh the pending count independently with regression coverage for a deferred device.pair.list.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection shows device.pair.setupCode can resolve and mutate setup state while openDevicePairSetup still waits for device.pair.list before publishing the non-loading snapshot.

Is this the best way to solve the issue?

No, not as written. The shared overlay is the right layer, but pending-count refresh must not gate QR/setup-code rendering before merge.

Full review comments:

• [P2] Publish the setup code before pending count returns — ui/src/app/overlays.ts:625
  This is the same publish-order blocker from the previous ClawSweeper cycle: openDevicePairSetup still waits for both the setup-code request and refreshDevicePairPendingCount() before publishing the completed overlay snapshot. If device.pair.setupCode succeeds but device.pair.list is slow or never replies, devicePairSetup is populated internally but listeners are not notified, so the dialog stays on the generating spinner instead of showing the QR code.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against f7d7148cf047.

Label changes:

• add merge-risk: 🚨 availability: The changed overlay flow can stall the shared pairing dialog when the pending-count RPC is slow even after the setup-code RPC succeeds.
• add proof: sufficient: Contributor real behavior proof is sufficient. The PR includes inspected browser screenshots of the sidebar entry, shared QR dialog, and Quick Settings entry, plus focused E2E and build evidence in the PR body.
• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR includes inspected browser screenshots of the sidebar entry, shared QR dialog, and Quick Settings entry, plus focused E2E and build evidence in the PR body.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (screenshot): The PR includes inspected browser screenshots of the sidebar entry, shared QR dialog, and Quick Settings entry, plus focused E2E and build evidence in the PR body.

Label justifications:

• P2: The PR addresses normal-priority mobile setup discoverability, but the remaining spinner bug has limited blast radius to the pairing dialog.
• merge-risk: 🚨 availability: The changed overlay flow can stall the shared pairing dialog when the pending-count RPC is slow even after the setup-code RPC succeeds.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (screenshot): The PR includes inspected browser screenshots of the sidebar entry, shared QR dialog, and Quick Settings entry, plus focused E2E and build evidence in the PR body.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR includes inspected browser screenshots of the sidebar entry, shared QR dialog, and Quick Settings entry, plus focused E2E and build evidence in the PR body.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR includes inspected browser screenshots of the sidebar entry, shared QR dialog, and Quick Settings entry, plus focused E2E and build evidence in the PR body.

PR surface:

Source +229, Tests +39. Total +268 across 17 files.

Acceptance criteria:

• [P1] node scripts/run-vitest.mjs run --config test/vitest/vitest.ui-e2e.config.ts --configLoader runner ui/src/e2e/mobile-pairing.e2e.test.ts.
• [P1] node scripts/run-vitest.mjs run ui/src/pages/config/quick.test.ts ui/src/pages/nodes/view.devices.test.ts ui/src/lib/device-pair-setup.test.ts.
• [P1] pnpm ui:build.

What I checked:

• PR head gates setup publication on pending count: openDevicePairSetup starts setup-code and pending-count requests, publishes the loading state, then waits for Promise.all([setupOperation, pendingCountOperation]) before publishing the completed snapshot. (ui/src/app/overlays.ts:625, 2c16a0ad1f23)
• Setup helper does not notify overlays by itself: refreshDevicePairSetup mutates devicePairSetup and clears loading, but it has no listener or publish hook; callers must publish after the setup operation completes. (ui/src/lib/device-pair-setup.ts:45, 2c16a0ad1f23)
• Gateway contract keeps list and setup-code independent: The protocol documents device.pair.list and device.pair.setupCode as separate device-pairing methods; rendering the QR/setup code does not depend on a successful list response. Public docs: docs/gateway/protocol.md. (docs/gateway/protocol.md:458, f7d7148cf047)
• Focused E2E covers the normal immediate-list path only: The PR E2E uses an immediate device.pair.list mock and verifies the happy path, so it does not catch a slow or deferred pending-count request blocking QR publication. (ui/src/e2e/mobile-pairing.e2e.test.ts:56, 2c16a0ad1f23)
• Current main still has only the original Nodes entry point: Current main renders the pairing setup button from the Nodes Devices card, so the discoverability feature remains unmerged and this PR is still relevant. (ui/src/pages/nodes/view.ts:61, f7d7148cf047)
• Visual proof inspected: The attached screenshots show the sidebar shortcut, the shared QR dialog, and the Quick Settings entry in a browser Control UI session.

Likely related people:

• bkudiess: Authored the merged PR that added the device.pair.setupCode Gateway method and original Control UI mobile-pairing flow this PR extends. (role: introduced behavior; confidence: high; commits: cf313b154848; files: src/gateway/server-methods/device-pair-setup.ts, packages/gateway-protocol/src/index.ts)
• steipete: Merged the original pairing PR, authored the current discovery PR, and recent blame/log history points to the current Nodes pairing UI files. (role: recent follow-up owner; confidence: high; commits: 089f8c1f6fce, aaaa8030bf4f, 2c16a0ad1f23; files: ui/src/app/overlays.ts, ui/src/pages/nodes/view-pairing.ts, ui/src/components/app-sidebar.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

• reviewed 2026-07-05T03:12:09.275Z sha d5fc815 :: needs maintainer review before merge. :: none
• reviewed 2026-07-05T03:48:03.595Z sha 2c19fdd :: needs maintainer review before merge. :: none
• reviewed 2026-07-05T03:54:59.631Z sha 5b5d9ce :: needs maintainer review before merge. :: none
• reviewed 2026-07-05T04:01:56.695Z sha 5b5d9ce :: found issues before merge. :: [P2] Publish the setup code before refreshing pending count