Best possible solution:

Land the static recovery panel and troubleshooting docs after maintainer review and green CI, while keeping the separate large-history freeze work tracked by the linked issue and existing responsiveness fixes.

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

Do we have a high-confidence way to reproduce the issue? No live browser-extension reproduction was established here, but source inspection shows current main has no static fallback before openclaw-app registration, so the blank-page failure mode is source-reproducible.

Is this the best way to solve the issue?

Is this the best way to solve the issue? Yes, the PR takes a narrow maintainable path by placing the recovery panel outside the Lit bundle, documenting the operator workaround, and adding focused isolated coverage; the linked large-history freeze remains a separate scope.

What I checked:

• Protected PR metadata: Live issue metadata shows this PR is open, authored by BunsDev with author association MEMBER, and labeled maintainer, so this cleanup workflow must keep it open for explicit maintainer handling. (548abf4e92c3)
• Current main has no static fallback: Current main renders only <openclaw-app> and the module script after the theme bootstrap, so a module-evaluation failure can still leave a blank static page. (ui/index.html:67, b41d766394e0)
• App registration depends on module execution: openclaw-app is registered in the module-loaded app code, matching the linked issue's source-reproducible blank-page path when module evaluation never reaches registration. (ui/src/ui/app.ts:1292, b41d766394e0)
• PR fallback implementation: The PR head adds fallback markup, retry/keep-waiting controls, and an inline timer that shows the panel only while openclaw-app remains unregistered. (ui/index.html:201, 548abf4e92c3)
• Focused PR coverage: The added test evaluates the fallback in an iframe-isolated window, checks the never-registered path, the keep-waiting rearm path, and the registered-before-timeout path. (ui/src/ui/mount-fallback.test.ts:49, 548abf4e92c3)
• Docs addition: The PR head adds public Control UI troubleshooting guidance for blank pages caused by extensions or early content scripts. Public docs: docs/web/control-ui.md. (docs/web/control-ui.md:428, 548abf4e92c3)

Likely related people:

• BunsDev: Prior merged Control UI work touches the index/docs/chat responsiveness surface, including the linked issue's large-history mitigation area; this PR also continues that focused recovery path. (role: recent Control UI contributor and likely follow-up owner; confidence: high; commits: df72ca1ecec7, 6b4ff8be81e7, 60171e863882; files: ui/index.html, docs/web/control-ui.md, ui/src/ui/app.ts)
• steipete: Recent history shows adjacent edits in Control UI docs and app/chat files, plus earlier index.html migration/rename work around the browser UI surface. (role: recent adjacent Control UI and docs contributor; confidence: high; commits: 743e543639a3, cb088c81601e, 6785633d137c; files: docs/web/control-ui.md, ui/src/ui/app.ts, ui/index.html)
• kvncrw: Recent merged work changed the Control UI document shell for iOS standalone behavior, which is adjacent to static index.html fallback behavior but not specifically tied to this bug. (role: recent adjacent index contributor; confidence: medium; commits: d22da8712662; files: ui/index.html)

Remaining risk / open question:

• The third-party Chrome extension blank-page path from the linked issue was not live-reproduced in this read-only review.
• The PR head currently has a failing aggregate check job, so normal CI follow-up is still required before merge.

Codex review notes: model gpt-5.5, reasoning high; reviewed against b41d766394e0.