resize_window (Claude in Chrome MCP tool) reports success but does not change the actual browser viewport

Tool: mcp__claude-in-chrome__resize_window (Claude in Chrome MCP server)

Environment:

• Claude Code: 2.1.220
• OS: Ubuntu 24.04.4 LTS (noble), kernel 7.0.0-28-generic, x86_64
• Chrome (via navigator.userAgent): Chrome/150.0.0.0 on X11/Linux
• Screen reported by the browser: 1366×768

Summary:
Calling resize_window with any width/height returns a success message and a matching confirmation string, but the tab's real viewport (window.innerWidth/innerHeight) never changes. Screenshots and DOM measurements confirm the browser continues rendering at its original size regardless of the requested dimensions.

Steps to reproduce:

1. Open any tab via tabs_context_mcp / tabs_create_mcp.
2. Call resize_window with { tabId, width: 375, height: 812 }.
3. Tool returns: Successfully resized window containing tab <id> to 375x812 pixels.
4. Run javascript_tool with action: "javascript_exec" and text: "JSON.stringify({innerWidth: window.innerWidth, innerHeight: window.innerHeight, outerWidth: window.outerWidth, outerHeight: window.outerHeight})".
5. Result does not reflect the requested size.

Expected behavior:
window.innerWidth/innerHeight (and subsequent screenshots) should reflect the requested dimensions, e.g. ~375 x ~812.

Actual behavior:
Regardless of requested size, measured viewport stayed fixed at:

innerWidth: 1168
innerHeight: 681
outerWidth: 1168
outerHeight: 681
devicePixelRatio: 1
screen.width: 1366
screen.height: 768

Test matrix (same tab, same session):

| Requested (w×h) | Tool response | Actual innerWidth×innerHeight after |
|---|---|---|
| 430×900 | "Successfully resized..." | 1168×681 (via screenshot) |
| 414×896 | "Successfully resized..." | 1168×681 (via screenshot) |
| 375×812 | "Successfully resized..." | 1168×681 (confirmed via window.innerWidth/innerHeight) |

Impact:
Any workflow that depends on resize_window to validate responsive/mobile layouts (e.g. testing CSS breakpoints, mobile-first PWAs) silently gets desktop-viewport screenshots while the tool reports success — there's no error signal that the resize didn't apply, which is what makes this dangerous rather than just cosmetic.

Workaround found:
Injecting an <iframe> with a fixed CSS width/height (e.g. 390×844) pointed at the target URL does trigger real CSS media-query evaluation inside the iframe, since the iframe's own box establishes its content viewport independent of the outer window. This is a functional substitute for verifying responsive layouts, but it's not a substitute for actually resizing the browser window (no OS-level window chrome behavior, no window.resizeTo semantics, etc.).

Environment notes:
screen.width/screen.height (1366×768) stayed constant across all requests, suggesting the underlying display/window may be running in a fixed-size (possibly containerized/virtual display) mode where resize requests are accepted but not applied — but this is a guess from the outside; no visibility into the extension/MCP server implementation to confirm root cause.