[BUG] Claude in Chrome: tab viewport silently collapses to 280x15 and never recovers; screenshot/left_click/resize_window all keep reporting success

Preflight Checklist

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

What's Wrong?

During a long browser-automation session (Outlook Web), one tab's render viewport silently collapsed to 280x15 CSS px. The tab became permanently unusable for automation — but every tool kept reporting success:

• computer{action:"screenshot"} -> Successfully captured screenshot (560x30, jpeg) (= 2x DPR of the 280x15 viewport; visually a single grey bar)
• computer{action:"left_click", coordinate:[241,312]} -> Clicked at (241, 312) — coordinates far outside the 280x15 surface, so the click cannot possibly have landed. No effect on the page, no error.
• resize_window({width:1400, height:900}) -> Successfully resized window containing tab <id> to 1400x900 pixels — the next screenshot was still 560x30. Called 3x, never recovered.

The only signal that anything was wrong was a Viewport: 280x15 line in the footer of read_page output.

A different tab in the same browser window screenshotted normally (1285x952) during the same period, so this is per-tab, not per-window.

Consequence: the agent repeatedly clicked a "Send" button that could never fire, receiving a success string on every call, and burned a large number of turns before recovering. The end user interpreted this as a model capability failure and switched models mid-session — it was not. Both models hit the same platform failure.

Related but distinct: #82373 covers resize_window ignoring requested sizes. This report is about a viewport that spontaneously becomes degenerate and is unrecoverable, plus tools returning success while inoperable. #87390 covers the generic "failed in the extension" errors also seen here.

What Should Happen?

1. The tab viewport should not be able to reach a degenerate size (280x15) in the first place.
2. If it does, resize_window should restore it — or return an error instead of a success string.
3. computer{screenshot} should return an explicit error when the capture is degenerate (e.g. either dimension < 200px), with a remediation hint, e.g. Viewport is 280x15; this tab may be in a broken state — recreate it with tabs_create_mcp.
4. computer{left_click} should reject or warn on coordinates outside the current viewport bounds, rather than returning Clicked at (x, y).
5. Viewport dimensions should be included in every computer/screenshot result, not only in the read_page footer.

Silent success is the worst possible failure mode for an autonomous agent: there is no signal to trigger a different strategy, so it loops on an action that can never work. Item 3 alone would have saved the majority of the wasted turns in this session.

Error Messages/Logs

read_page(tabId: 886497232)
  -> ... Viewport: 280x15

computer{action:"screenshot", tabId:886497232}
  -> Successfully captured screenshot (560x30, jpeg)

resize_window{width:1400, height:900, tabId:886497232}
  -> Successfully resized window containing tab 886497232 to 1400x900 pixels

computer{action:"screenshot", tabId:886497232}
  -> Successfully captured screenshot (560x30, jpeg)      <-- unchanged

computer{action:"left_click", coordinate:[241,312], tabId:886497232}
  -> Clicked at (241, 312)                                <-- no effect on page

# healthy tab, same window, same session, same minute:
computer{action:"screenshot", tabId:886497316}
  -> Successfully captured screenshot (1285x952, jpeg)

# also observed in this session (cf. #87390):
8x  Tool "computer" failed in the extension
8x  Tool "navigate" failed in the extension

Steps to Reproduce

Not deterministically reproducible on demand — it emerged after prolonged interaction. Conditions present when it occurred:

1. Open a tab via tabs_create_mcp and navigate to a complex SPA (outlook.live.com, new Outlook Web UI).
2. Drive it heavily for an extended period: many computer{left_click} / {key} / {type} calls, several javascript_tool calls, find + ref-targeted clicks, with a modal compose window open.
3. At some point computer{screenshot} starts returning a 560x30 image.
4. read_page footer now reports Viewport: 280x15.
5. resize_window to any size returns success but does not restore the viewport (repeated 3x to confirm).
6. All subsequent clicks return Clicked at (x, y) and do nothing.

Workaround (100% effective): tabs_create_mcp -> navigate to the same URL in the fresh tab. The new tab came up at a normal 1285x952 viewport and the previously-failing click worked on the first attempt. The broken tab never recovered.

Possibly relevant mechanism: on a healthy tab in this same session, javascript_tool reports innerWidth === outerWidth (756x404, dpr 2, screen 1512x982). outerWidth should normally exceed innerWidth by the window chrome; the equality suggests a CDP viewport override is in effect, which may be the mechanism that can get stuck at a degenerate size. Cf. #78548, #74747.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.235 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Chrome 151.0.0.0 on macOS (navigator.userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ... Chrome/151.0.0.0). Host: Cowork mode (Claude Agent SDK), cloud session; browser tools via the Claude in Chrome MCP server. The "Terminal/Shell" and "Platform" fields below are not really applicable — this is not a terminal session.

Two further observations from the same session, included as context (happy to split into separate issues if preferred):

1. Two MCP tab groups coexisted. tabs_context_mcp returned two different tabGroupId values (56431490 and 1235971163) within one session, each listing a different set of tabs. Tab IDs returned by one call were unusable by tools driven from the other, producing the generic failed in the extension errors above.

2. Double execution of input actions. computer{type} inserted its text twice; a single BackSpace/Delete removed two characters; and javascript_tool running document.execCommand('insertText', ...) applied the insertion twice. Because it duplicated even for a JS execCommand call, the duplication appears to be at the tool-dispatch/transport layer rather than in the page or in model output. The workaround was to make the operation idempotent (assign element.innerHTML directly, then dispatch a synthetic InputEvent). Lower confidence than the rest of this report: raw logs for that portion of the session were lost to context compaction, so this rests on contemporaneous notes rather than primary logs.

Suggested fix priority (highest value/effort ratio first): fail loudly on degenerate viewports; surface viewport dimensions in every computer/screenshot result; make resize_window verify and report the actual resulting viewport; add idempotency keys to tool dispatch.