Best possible solution:

Accept or narrow the durable-dashboard-MCP-App product direction as one feature series, land the backend prerequisite first, then rebase this UI PR and prove a persisted widget through a real Gateway with its required exact-head checks green.

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

Not applicable: this is a feature PR, not a report of broken established behavior. The relevant validation path is an after-fix persisted-widget flow through the real Gateway rather than a current-main failure reproduction.

Is this the best way to solve the issue?

Unclear. The UI/provider/handler split is internally coherent, but the best permanent solution depends on maintainer acceptance of the durable MCP App dashboard contract and proof against the real backend prerequisite.

AGENTS.md: found and applied where relevant.

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

Label changes:

• add merge-risk: 🚨 compatibility: The branch adds a Gateway method and changes durable MCP App widget data across protocol, storage, desktop/mobile models, and the web UI.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body reports focused tests and a real Chromium run, but the E2E uses a mocked Gateway; add redacted proof of a persisted MCP App widget being restored and rendered through the real Gateway, including lease-expiry or restart behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• remove rating: 🦐 gold shrimp: Current PR rating is rating: 🦪 silver shellfish, so this older rating label is no longer current.
• remove status: 👀 ready for maintainer look: Current PR status label is status: 📣 needs proof.

Label justifications:

• P2: This is a substantial but non-emergency dashboard capability whose remaining work is maintainer acceptance and integration validation.
• merge-risk: 🚨 compatibility: The branch adds a Gateway method and changes durable MCP App widget data across protocol, storage, desktop/mobile models, and the web UI.
• merge-risk: 🚨 security-boundary: The app-view path remints leases and authorizes interactive MCP App capabilities from persisted widget authority, which requires end-to-end boundary verification.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body reports focused tests and a real Chromium run, but the E2E uses a mocked Gateway; add redacted proof of a persisted MCP App widget being restored and rendered through the real Gateway, including lease-expiry or restart behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

PR surface:

Source +888, Tests +1225, Other +67. Total +2180 across 37 files.

What I checked:

• UI lifecycle implementation: The UI cell owns visibility-gated materialization, lease renewal, stale recovery, and teardown, while the board view supplies the provider callback for the new app-view flow. (ui/src/components/board/board-widget-cell.ts:1, 17dd3215989b)
• Gateway authority path: The new board handler validates the app-view request and connects it to MCP App active-view resolution and transcript reconstruction, making this a cross-layer feature rather than a UI-only change. (src/gateway/server-methods/board.ts:1, 17dd3215989b)
• Focused browser coverage: The branch adds a Chromium Control UI E2E scenario for sandbox/frame mounting, renewal, and avoiding eager materialization of offscreen cells; the PR body identifies its Gateway as mocked, so it is useful supplemental coverage rather than real integrated behavior proof. (ui/src/e2e/board-mcp-app.e2e.test.ts:1, 17dd3215989b)
• Prerequisite feature series: The PR explicitly depends on the still-open backend/persistence companion at feat(dashboard): persist MCP Apps as board widgets #111552, whose head is the stacked base commit used by this branch. (src/boards/board-store.ts:1, 7ed78c78627c)
• Repository policy applied: The root review policy requires whole-surface review, maintainer handling for larger product/security-sensitive behavior, and proof that matches the actual integration risk; this PR changes gateway protocol, persisted widget metadata, and UI lifecycle behavior. (AGENTS.md:1, eb3a600571fd)

Likely related people:

• fuller-stack-dev: Authored the connected backend persistence work and the UI renderer/lifecycle commit sequence, giving them clear cross-layer context for the proposed dashboard MCP App feature. (role: feature-series author; confidence: medium; commits: 4513825130a3, 7ed78c78627c, 17dd3215989b; files: src/boards/board-store.ts, src/gateway/server-methods/board.ts, ui/src/components/board/board-widget-cell.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-20T01:47:58.631Z sha 17dd321 :: needs maintainer review before merge. :: none