[Bug]: Empty browser threads report automation unavailable #30061

Before submitting

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

Area

apps/server

Steps to reproduce

1. In a thread with no Browser tabs open, call preview_status.
2. Observe available: false, visible: false, and tabId: null.
3. Call preview_open({}) anyway. A tab opens successfully.
4. Close the last tab and call preview_status again: it returns available: false again.

Expected behavior

A thread without an open tab should not imply that browser automation is unavailable. Agents should open a tab before deciding that browser verification is unsupported.

Actual behavior

ServerBrowser.statusWithTitle returns available: false solely because the thread has no tab. An agent interpreted this as the built-in browser being unavailable and stopped verification; on retry, the same status was followed by a successful preview_open.

The repository's test-t3-app skill reinforces the mistake: it says to stop when the panel reports unavailable, although its later instructions say to open the panel when closed.

Impact

Minor bug or occasional failure: agents can abandon otherwise-working browser verification until the user tells them to retry.

Version or commit

Reported on 0.1.7-nightly.20261103.4119; the same no-tab branch is present on main at cefb544af3c98224874419198c0359b652ca3c94.

Environment

Linux desktop, Codex agent. The status response is produced by the shared server browser service.

Logs or stack traces

preview_status: available=false, visible=false, tabId=null
preview_open({}): available=true, tabId=<new tab>
close last tab
preview_status: available=false, visible=false, tabId=null

A focused regression test reproduces the false availability result on the original code. A production browser-service run with real Chromium and isolated temporary state also confirms that opening works and that the corrected status can stay available before opening and after closing the last tab.

Workaround

When status has tabId: null, try preview_open({}) before declaring browser automation unavailable. Use the opening error, if any, to diagnose actual support or installation problems.