Browser

browser drives the clean Chromium inside the sandbox: none of your logins, and it never touches your own browser. Use it for public web research, screenshotting pages you are building, and running automation.

Activation

profy-browser is user_selectable: true with no other prerequisite — no desktop app required, the cloud sandbox is enough. Tick it in the plugin panel.

The 12 actions

Action	Parameters	Notes
`navigate`	`url`, `new_tab`	Open a URL
`screenshot`	`url` / `html` / `file_path`, `full_page`, `ref`, `viewport_width`, `viewport_height`, `wait_ms`	Three sources, see below
`snapshot`	optional `selector`	Accessibility tree plus element refs — required before interacting
`click`	`ref` (required), `button`, `double_click`	Without a ref: `'ref' is required for click action. Use snapshot first to get element refs.`
`type`	`ref`, `text`, `clear`, `submit`	Keystroke by keystroke
`fill`	`ref`, `text`	Sets the value directly, faster
`scroll`	`direction`, `amount`, `ref`	—
`press_key`	`key` (required)	—
`tabs`	`tab_action` (list / new / close / select), `tab_index`	Tab management, no claiming needed
`set_html`	`html` (required)	Inject HTML with zero servers
`evaluate`	`code` (required), optional `url`	Run JS in the page and return the result — this is how you assert state
`go_back`	—	History back

Diff snapshots: why the second snapshot is tiny

The first snapshot returns the full accessibility-tree YAML. Every one after that returns only a unified diff against the previous. On a stable page, follow-up snapshots are typically under 100 tokens. The point is to make “observe the page repeatedly” affordable in a long session instead of a context-budget bonfire.

Diff state lives in process, scoped per session, and is lost on restart — the first snapshot after a restart returns the full tree again. That is state rebuilding, not an error.

Action self-verification: did the click actually do anything?

click / type / fill / press_key come with automatic verification:

Snapshot before the action
Execute
Snapshot again and compare
No change → wait 500 ms and retry, up to 3 attempts
Still no change → the result is explicitly marked verified: false

The value of this loop: it turns “clicked but nothing happened” from a silent failure into an explicit signal. You see how many attempts were made and whether the page moved, instead of seeing “click succeeded” followed by everything downstream being wrong.

verified: false does not mean the action definitely failed. Some interactions genuinely do not change the accessibility tree — copying to the clipboard, firing a background request. It only says “no change visible from the accessibility view,” and the expert has to judge from context.

Three screenshot sources

1. A running page

browser(action="screenshot", url="http://localhost:5173")

2. Injected HTML (zero servers)

browser(action="screenshot", html="<html><body><h1>Hello</h1></body></html>")

No server needed — good for quickly verifying a generated HTML fragment. 3. A local file

browser(action="screenshot", file_path="/home/user/workspace/demo.html")

Starts a static server automatically, which matters for HTML with relative asset references. Custom viewport and full-page capture:

browser(action="screenshot", url="http://localhost:5173",
        viewport_width=1920, viewport_height=1080, full_page=True)

Screenshots land on the sandbox filesystem and are returned as paths, never as base64 in the tool result — base64 would burn the context instantly. The image tool reads them by path when they need to be looked at.

Standard workflow

browser(action="navigate", url="https://example.com/form")
browser(action="snapshot")
# → [0] input "Name"  [1] input "Email"  [2] button "Submit" ...

browser(action="fill", ref="input[0]", text="John Doe")
browser(action="fill", ref="input[1]", text="john@example.com")
browser(action="click", ref="button[2]")
# → auto-verified: did the page change?

browser(action="evaluate", code="document.querySelector('.toast')?.textContent")
# → assert the submission result; more reliable than reading a screenshot

evaluate is the key step: assert instead of eyeballing a screenshot. Screenshots lie (render timing, loading states); DOM queries do not.

Failures and what to do

Error	Meaning	Fix
`Error: Sandbox not available. Cannot control browser.`	No sandbox available	Send a message first to provision one
`'ref' is required for click action`	Snapshot was skipped	Run `snapshot` to get refs
`'key' is required for press_key action`	Missing key name	Supply it
`'html' is required for set_html action`	Missing HTML	Supply it
`'code' is required for evaluate action`	Missing code	Supply it
`Unknown browser action '...'`	Misspelled action	Check the 12 above
`verified: false`	Page unchanged after three retries	Try another locator, or confirm state with `evaluate`
Content that requires login	The sandbox browser has no session at all	Switch to the `chrome` plugin (your own browser)

Execution path

On desktop, calls prefer the sidecar (Playwright inside Electron); in the cloud they run Playwright over CDP inside the sandbox (CDP port 9222, noVNC port 6080). Both routes expose the same actions with the same behavior.

Known limitation: the Browser Use settings panel is not wired up. Its toggles (enabled, web URL, browsing data, annotation screenshots) and the safety-tier dropdown (read / click / full) are component-local state today — neither persisted nor consulted at runtime. Changing them does not change what the expert can do. The real isolation comes from the sandbox itself: that browser holds none of your data.

Choosing between browser, chrome, and computer

Dimension	`browser`	`chrome`	`computer`
Browser	Isolated sandbox Chromium	Your own Chrome	The whole desktop
Session	None	Yours	Whatever the desktop has
Prerequisite	None	Desktop app + extension	Desktop app
Confirmation	Not needed (already isolated)	Four tiers	Desktop permissions
Tabs	Created freely	Requires `claim_tab`	—
Best for	Public research, dev self-checks, parallel work	Sites that need a login	Native applications

The rule is simple: public content goes to browser (faster, isolated, never touches your data); escalate to chrome only when a session is required.

Keep reading

Chrome

Browser control with your session

Computer Use

Pixel-level desktop control

Sites

Where screenshot verification fits in a build

Tool catalog

Full parameters for every action

Get Started

Core Concepts

Guides

Platform & Account

Deep Dive

Activation

The 12 actions

Diff snapshots: why the second snapshot is tiny

Action self-verification: did the click actually do anything?

Three screenshot sources

Standard workflow

Failures and what to do

Execution path

Choosing between browser, chrome, and computer

Keep reading

Chrome

Computer Use

Sites

Tool catalog

​Activation

​The 12 actions

​Diff snapshots: why the second snapshot is tiny

​Action self-verification: did the click actually do anything?

​Three screenshot sources

​Standard workflow

​Failures and what to do

​Execution path

​Choosing between browser, chrome, and computer

​Keep reading

Chrome

Computer Use

Sites

Tool catalog

Activation

The 12 actions

Diff snapshots: why the second snapshot is tiny

Action self-verification: did the click actually do anything?

Three screenshot sources

Standard workflow

Failures and what to do

Execution path

Choosing between browser, chrome, and computer

Keep reading