Chrome extension backend does not expose viewport capability for @Chrome browser tasks

Summary

With the current Codex @Chrome / Chrome extension backend, I can connect to the browser and read already-open user tabs successfully, but the backend does not expose any viewport / resize capability. As a result, I cannot use the official @Chrome path for fixed-size or responsive breakpoint testing.

This looks like either:

• a real feature gap / capability mismatch, or
• a limitation that should be explicitly documented for the @Chrome backend.

Environment

• macOS 15.7.4
• Test date: 2026-05-20
• Local Chrome plugin path: openai-bundled/chrome/0.1.7
• Comparison target: in-app Browser plugin path: openai-bundled/browser/0.1.0-alpha2

Reproduction steps

1. Connect to @Chrome through the official Chrome extension backend.
2. Run a lightweight connectivity check with browser.user.openTabs().
3. Inspect browser-scoped capabilities with await browser.capabilities.list().
4. Try to read the viewport capability with await browser.capabilities.get("viewport").
5. Create a new tab, then inspect tab-scoped capabilities with await tab.capabilities.list().

Actual result

• browser.user.openTabs() succeeds, which shows that the extension connection is healthy.
• await browser.capabilities.list() returns [].
• await browser.capabilities.get("viewport") throws:

Error: Capability is not available: viewport

• After creating a new tab, await tab.capabilities.list() also returns [].

Expected result

At least one of the following should be true and explicit:

1. The @Chrome backend supports a viewport capability similar to the in-app Browser backend, for example:

• set({ width, height })
• reset()

1. If this is an intentional limitation, the official documentation should state clearly that:

• the @Chrome backend does not currently support viewport/resize overrides
• authenticated pages that require the user's real browser session cannot currently be tested at specific device sizes or responsive breakpoints through the official browser-use API

Why this matters

@Chrome is the correct backend for workflows that must reuse:

• the user's real logged-in session
• existing browser cookies/context
• already-open tabs in the external browser

Without viewport override support, several common and important workflows are blocked, for example:

• mobile-width regression checks after login
• UI verification at specific responsive breakpoints
• screenshots and debugging for authenticated pages under different viewport sizes

These are exactly the cases where falling back to the in-app Browser is often not acceptable, because the login state and browser context are different.

Additional context

I am filing this as an issue instead of assuming user error because:

• the extension backend is clearly connected and working well enough to return real open tabs via openTabs()
• the capability list is empty
• viewport is reported as explicitly unavailable
• the in-app Browser backend on the same machine does have separate viewport capability documentation

If this is a planned gap in the roadmap, it would still help to document it directly.