[Bug]: Failed browser preview remains as a blank floating panel

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Open a Codex-backed thread in T3 Code Desktop.
2. Call preview_open with open: true.
3. Navigate the preview to an unavailable local URL, or stop the target server.
4. Confirm that preview_evaluate reaches chrome-error://chromewebdata/.
5. Continue working in the thread without manually closing the preview.
6. Observe the floating preview at the top-right of the chat.

Expected behavior

A failed preview should show a clear error state with Retry and Close controls.

preview_status should report the navigation failure or effective error URL.

The preview should not remain as an unexplained white rectangle.

Actual behavior

The mini-player remains visible as a blank white 320 × 200 panel. Only a small gray dot and resize handle identify it as interactive.

Observed timeline:

• preview_open(open:true) created tab_2.
• preview_snapshot failed with PreviewAutomationExecutionError.
• preview_evaluate returned chrome-error://chromewebdata/ with an empty title and body.
• preview_status still returned available:true, loading:false, and the requested URL.
• A later capturePage operation waited 305.5 seconds and failed with UnknownVizError.
• The blank floating panel was still visible 18 minutes after it opened, after the agent had changed to Chrome automation.

The panel is T3 Code's ThreadPreviewMiniPlayer, not Computer Use. Its default size, edge offset, status dot, and resize handle match the screenshot exactly.

The component renders BrowserSurfaceSlot while desktopOverlay.hasWebContents is true. A failed navigation still has WebContents, so the Reconnecting preview… state is not shown. The mini-player is only cleared when the tab disappears, the same tab opens in the right panel, or the user closes it manually.

Impact

Major degradation or frequent failure.

The blank panel covers chat content and hides the browser failure. The agent can also continue using a broken preview tab because status reports it as healthy.

Version or commit

• T3 Code 0.0.34-nightly.20260816.1108
• Commit 4cb676cc1612

Environment

• macOS 26.1, Apple Silicon
• T3 Code Desktop
• Codex provider
• Embedded collaborative browser preview

Logs or stack traces

preview_snapshot -> PreviewAutomationExecutionError
preview_evaluate -> chrome-error://chromewebdata/
preview_status -> available:true, visible:false, loading:false, requested URL
PreviewManager.captureAutomationSnapshot -> 305518 ms -> UnknownVizError

No Computer Use tool event occurred in the affected thread.

Screenshots, recordings, or supporting files

Workaround

Hover the gray dot and close the floating preview. Open a fresh preview tab if automation is required.

Related issues

• #3713
• #3718
• #6355
• #7200

Start by tracing ThreadPreviewMiniPlayer and its BrowserSurfaceSlot condition in apps/web, then follow PreviewManager.captureAutomationSnapshot and the preview_status path. Reproduce the unavailable-URL flow and inspect how failed navigation is represented. Done means the panel exposes a clear failure state with Retry and Close controls, while status reports the navigation failure or effective error URL.