Document access and browser limits

Unrestricted document targets, browser inspection limits, and original document bytes.

Policy, not a new browser privilege

The issue #18 change removes Browser MCP’s document URL/origin restrictions. An owner-authorized client may target documents exposed by its paired browser without a product-level veto based on the top-level URL, descendant frame, effective inherited origin or opener. This includes the application’s own control-plane origin and browser-internal/extension documents. It does not make every Chrome target inspectable or every operation available.

Chrome, its extensions and the site’s own behavior still determine which frames, DOM, pixels and protocol operations are available. A target may be visible yet refuse evaluation, printing or a screenshot; an internal viewer may expose only its toolbar. Cross-origin page-script restrictions remain, even where Playwright/CDP can separately target a frame. The runtime does not disable web security, expose a remote CDP listener, attach to arbitrary browsers or add shell/filesystem commands.

Allowing a file: document is browser-level access, not a new file-transfer path API. Where Chrome permits it, that document can reveal files readable by the browser’s OS account. Do not give an automated profile access to sensitive local files merely because transfer tools accept only staged resource IDs.

Authority that remains separate

Requests still require the correct authenticated browser credential and session, current runtime instance and applicable tab claim. Document access does not authorize another client’s resources, bypass a local pause, revive revoked credentials or grant a new transfer capability. Opener origin restrictions are removed, not popup ownership inheritance. These mechanisms coordinate tool access; a shared profile is not an isolation boundary against a malicious authorized client. Use separate profiles for different trust domains.

A signed-in control-plane page is now within browser authority. Its UI or same-origin JavaScript requests can use dashboard cookies to manage browsers, create/revoke client credentials, approve device pairing or perform administrative operations allowed by that dashboard account. Same-origin checks and HttpOnly cookies do not isolate that signed-in page from its authorized browser controller. Use a separate non-automated profile for administration unless this authority is intentionally delegated. See security and trust limits.

Choose the path that matches the task

Need	Path	What the result establishes
Inspect accessible controls or page text	browser_read_page, browser_inspect, frame selectors	The accessible DOM/outline observed, not the complete source document.
Inspect visible document appearance	browser_screenshot, where Chrome permits	Pixels of the captured region, not selectable text or original bytes.
Interact with a viewer or internal page	Normal browser input, or explicitly authorized browser_run_js where supported	An attempted/successful browser operation, not a bypass of Chrome restrictions. Verify the resulting state.
Print a page to PDF	browser_export_page with PDF format, where supported	A generated print rendering, not the original PDF or proof of completeness.
Obtain original file bytes	The site’s/viewer’s actual download, then browser_list_downloads and browser_create_download	The exact completed Chrome download captured by the runtime, subject to retention and transfer limits.
Save bytes accessible to an authorized page script	browser_run_js and its bounded r5dCreateArtifact helper	The bytes supplied by that script; it is not an automatic document-fetch or PDF-decoding service. Normal fetch/origin rules still apply.

For the file-transfer contract, expiry, integrity checks and recovery, see files and secret exports. Download links are narrow short-lived bearer authority, not permission to disclose a document to an unrelated destination. Never forward dashboard cookies or broad MCP/runtime tokens to retrieve document bytes.

PDF and embedded viewer caveats

An inline PDF can be rendered by Chrome’s internal PDF extension or embedded viewer rather than an ordinary HTML document. Reading the viewer DOM may return navigation controls with little or none of the PDF text. A successful screenshot shows only captured pixels; it does not prove all pages loaded, extract text, or preserve the original file. A URL ending in .pdf is only a hint, and a PDF need not have that suffix.

Page printing is a separate output path. Print CSS, scroll containers, collapsed sections, lazy content and images can change or omit content. Successful byte generation is not proof that every source page, attachment, annotation or image is present. Do not label a print rendering as an original download.

When the task needs complete text or the original document, prefer a real source download/export and process those bytes with appropriate document tools outside the browser. Verify size and SHA-256 on transfer and inspect the resulting document for the task’s completeness requirements. An authenticated POST, blob URL or one-use download must be captured from the actual browser download rather than reconstructed by replaying its URL. Do not improvise PDF decoding in page scripts as a substitute for obtaining the source file.

Unsupported and uncertain operations

Use browser_capabilities for available operation information, but distinguish metadata or target classification from a successful operation. Neither an unrestricted target policy nor a capability advertisement guarantees that Chrome will perform the requested action. If Chrome refuses an operation, report that specific limitation and choose an authorized alternative; do not repeatedly retry it or weaken browser security.

A timeout/disconnect after input dispatch may mean the action happened. Inspect runtime health and the resulting state before proceeding; never replay an uncertain mutation automatically. Removing URL restrictions does not change recovery consent, quarantine, transfer expiry or revocation rules.