[BUG] Cowork built-in browser panel disappears after app update 2.2553.0 → 2.2553.1.0 (Windows): its tools return 400, then vanish from the tool set after restart

The report names no repository files, tests, or code entry point; start by reproducing the regression on Windows across app versions 2.2553.0 and 2.2553.1.0 with the built-in browser selected. Compare the Cowork panel, tool registration, Preferred browser setting, and app logs, then confirm the browser works or that unavailable-component state is surfaced with a fallback or clear error.

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

After the desktop app updated from 2.2553.0 to 2.2553.1.0 on Windows, the Cowork built-in browser panel is gone. It is no longer visible in the UI, and the tools it provides no longer work.

Before restarting the app: the panel's tools were still registered in the session's tool set, but every call failed with HTTP 400 (tried tabs_context, preview_start).

After a full restart of the app: the tools disappeared from the tool set entirely — calls return "tool not found", and two independent tool-search queries return only claude-in-chrome. Restarting made the situation strictly worse: before it, the tools at least registered.

Still reproducing in a fresh session later the same day.

The MCP bridge is not down. In the very same sessions, the Filesystem MCP server works (list_allowed_directories and list_directory return correct results for all configured roots) and the Claude in Chrome extension is connected and active (one browser registered, Windows, local, marked inUse; a tab group is created on demand). Only the built-in browser component is affected.

The setting points at a component that is not there. Settings → Cowork → Preferred browser was still set to the built-in browser, i.e. the app was routing browser work to a runtime that no longer exists in the session. There was no notice, no fallback and no error surfaced in the UI — the failure only became visible as tool-level 400s.

The Windows build did not change between the working and the broken state (same build before and after), so the regression window is a single app patch version.

What Should Happen?

Either the built-in browser panel keeps working after the update, or — if it was intentionally removed or gated — the Preferred browser setting reflects that and the app says so, instead of silently routing to a missing component and failing with an opaque 400.

Workaround currently in use: Preferred browser switched to Claude in Chrome.

Error Messages/Logs

Before app restart (panel tools still registered in the session):
  tabs_context   -> HTTP 400
  preview_start  -> HTTP 400

After a full restart of the app:
  tabs_context   -> tool not found
  preview_start  -> tool not found
  tool search for the panel's tools -> only `claude-in-chrome` is returned

Same session, working as a control:
  Filesystem MCP  list_allowed_directories -> OK (all configured roots)
  Filesystem MCP  list_directory           -> OK
  Claude in Chrome extension               -> connected, one local browser, inUse

Steps to Reproduce

This is an app/runtime regression, not a code-level bug, so there is no minimal code example — the steps below are the full reproduction.

1. On Windows, run the Claude desktop app 2.2553.0 with Settings → Cowork → Preferred browser set to the built-in browser. Open a Cowork session and use the built-in browser panel — it works.
2. Let the app update to 2.2553.1.0. (Windows build unchanged: 11 Home 25H2, Build 26200.9457.)
3. Open a new Cowork session. The browser panel is no longer visible in the UI.
4. Call any panel tool, e.g. tabs_context or preview_start. The tools are still listed in the session, but every call fails with HTTP 400.
5. Fully restart the app and open a new session.
6. Call the same tools again — they are now absent from the tool set entirely ("tool not found"); a tool search returns only claude-in-chrome.
7. In the same session, call Filesystem MCP list_allowed_directories — it works; check the Claude in Chrome extension — it is connected and usable. The bridge is therefore intact.
8. Open Settings → Cowork → Preferred browser — it is still set to the built-in browser, with nothing indicating that the component is unavailable.

Reproduced again in a fresh session several hours later, same result as step 6.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.2553.0 (Claude desktop app for Windows)

Claude Code Version

2.2553.1.0 (Claude desktop app for Windows — this report is about the desktop app / Cowork, not the CLI)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment — the two lines that narrow the regression window:

The OS build did not move; the app moved by one patch inside the same branch. So this is not a Windows-side regression.

Possibly related observation, offered as a coincidence in time only — no connection claimed: a separate defect open here since 2026-09-15, where every Filesystem MCP call failed with invalid outputSchema (connector schema draft-07 against a 2020-12-only validator), no longer reproduces on 2.2553.1.0.

Happy to provide exact timestamps of the failing calls, the tool-list output showing the missing tools, and app logs on request.