Batched snapshot–act–verify work
Use run for a bounded multi-step task. Its sandbox is neither Node nor the page: read through page.snapshot, page.read, or page.grep rather than assuming fetch, require, or document is in scope.
BrowserOS
BrowserOS neo is a dedicated browser for agents you already use. Connect over local MCP, group work into named sessions, and inspect live activity or hand a blocked step to a person without moving the task into a new model service.
Verify a BrowserOS connection
A connection check should prove that the agent sees and can act on the intended page, rather than merely reporting that an endpoint was configured.
Test URL, neo MCP connection, target control, expected page state, and the specific permitted action or an explicit read-only inspection limit.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatYour request for Floatboat
Preview and copy the request. It is not sent automatically from this page.
Reference: BrowserOS https://github.com/browseros-ai/BrowserOS Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Using the configured BrowserOS neo connection, open the supplied test URL, inspect the named control, and perform only the permitted action. Compare the resulting page state with the supplied expectation; report connection or observation failures without changing account settings. Expected deliverable: A connection check with visible tools, page title, and one observed interaction. Include failed steps and unresolved questions when evidence is insufficient.
About BrowserOS
BrowserOS is an agent-browser project; the current neo product is a secondary browser dedicated to external agents. It can import existing browser logins and exposes a local MCP connection for clients including Cursor and Codex. The external host retains the conversation and model while BrowserOS supplies browser state, task visibility, and interaction tools.
The browser’s MCP page provides connection helpers for recognized clients and a displayed endpoint for manual setup. Its port varies across builds, so copy the actual URL rather than assuming a fixed address. A companion browseros-neo Skill describes the tool surface. Installing that Skill without a live MCP connection does not make snapshot, act, or run available.
Neo prefers a bounded run script for multi-step work, keeping snapshot, action, and verification together. Named sessions group activity in the cockpit, and human-help tools handle login or other blocked steps. These current neo mechanisms should not be mixed with older BrowserOS extension tutorials. Floatboat can use the corresponding manual external-agent MCP route; the repository is AGPL-3.0, separately from host model and account access.
Keep Browser Work in One Observable Session
The local endpoint supplies tools, a named session makes activity recognizable, and run batches related steps. These mechanisms work together, but each has a boundary: connection is not authentication, a tab ID is not permanent, and a script has a fixed execution limit.
Settled changes and current refs
act returns a settled diff, while navigation returns after the page has stopped changing. Read that result instead of adding an arbitrary delay; take a fresh snapshot when refs have become stale.
Visible sessions and human help
name_session labels work in the cockpit. request_human_help and its wait flow let a person resolve login or approval, after which the agent can continue from the actual browser state.
BrowserOS Neo Tasks with Visible State
Use neo when an external agent needs a browser session the user can observe and resume. Repository checks, account reports, human checkpoints, and session review produce different results; retain the labels and evidence that make each one understandable in the cockpit.
Check a repository’s staging change
Provide a reachable staging URL, changed control, and expected behavior. Name the session for the feature and use one bounded run to inspect the page, perform the action, and read the result. Return the relevant code question with actual browser state, so the repository conversation does not lose the connection between change and symptom.
Read a workspace-specific report
Supply the portal, approved organization, period, and output fields. Open an agent-owned task tab and read only the relevant report. Return the active organization and dates with values; a successful local MCP connection does not establish that the imported account is the one requested.
Resume after a person completes login
When the page requires an account choice or one-time code, use request_human_help with the reason and intended next step. Wait through the documented status flow without acting on the page. After the user resolves it, inspect the current state and continue only the permitted next action; cancellation or timeout is a separate outcome.
Review where a browser run went wrong
Use the named session’s activity and available local replay evidence to locate the last completed action. Compare that point with the requested task and captured run logs. Keep a site error, stale handle, and roughly 30-second run timeout distinct; each needs a different recovery rather than a blind replay of the entire job.
Prepare Neo, MCP, and the Report Inputs
The walkthrough uses an external host and a small account-specific report. Prepare the live browser connection separately from the website account; the official Skill helps operate tools, while the browser’s MCP panel supplies the endpoint for this installation.
Current BrowserOS neo build
Install the supported build for the system and complete browser onboarding. Use current neo instructions; legacy browser-extension setup can describe a different product generation.
Connected external host
Use the MCP panel’s Connect action for recognized clients and restart the client. For other hosts, copy the displayed endpoint and add a Streamable HTTP MCP server; do not assume a fixed port or that Skill installation created the connection.
Report scope and account
Provide the portal URL, intended account or organization, reporting period, required fields, and read-only task. Decide whether the user will be available if the browser requests login help.
Read a Portal Report Through a Named Neo Session
Use the tool descriptions supplied by the live server for exact inputs. This sequence keeps report reading in bounded work units and uses the browser’s own human-help flow when needed; missing tools or unresolved login should produce an explicit blocker rather than a fabricated report.
Confirm tools and label the task
Check that snapshot, act, run, navigate, and tabs are available. If absent, fix the browser or MCP connection through neo’s MCP page. Call name_session with a short task name and non-sensitive summary so the work is recognizable in the cockpit.
Open the task page and confirm the account
Use tabs with action new for the task and open the supplied portal. Inspect the organization and report period before extracting fields. If login or account selection blocks progress, request_human_help; while status is waiting, use await_human_help and leave the page unchanged until resolved or ended.
Read the report in a bounded run
Use run to derive the current page and compose snapshot, any required action, and page.read or page.grep in one script. Select refs from the current snapshot. The runtime is not Node or the page, and a run is capped at 30 seconds; split work across smaller units rather than increasing the timeout or carrying stale page IDs forward.
Interpret readback and deliver the table
Read the action’s settled diff and returned fields; navigation already waits for settled state, so avoid an extra arbitrary sleep. Return the URL, account or organization, period, values, and missing fields. Read captured logs for a failed run and distinguish a timeout from a site error. Preserve useful review tabs unless cleanup is requested.
Related Software Projects
Compare the workflows, operating requirements, and source licenses of these projects.
BrowserOS FAQ
Where should the MCP endpoint come from?
Use the URL displayed in the installed browser’s MCP page. Ports differ across builds. Supported clients have connection helpers; an unlisted host uses the manual Streamable HTTP path rather than a guessed address.
Why prefer run to a long chain of tool calls?
It composes related observations and actions in one bounded script, reducing intermediate handle passing. Granular tools still fit a one-off step or debugging. Read the current API: the sandbox does not provide Node modules or a page document object.
Should I wait after every navigation or action?
Not with an arbitrary delay. Navigation returns after page changes settle, and act returns a settled diff. Use those results; for a genuinely asynchronous condition, wait for the expected text or selector using the documented interface.
How do I recover from a roughly 30-second run failure?
Inspect the error and captured logs. The hard wall-clock cap cannot be extended; split fresh navigations and other work into smaller calls, then re-derive the page. Do not assume a previous page ID still identifies an open task tab.
What if the user must sign in?
Use request_human_help and its status-based wait flow when available. Resume only after resolved, and report cancellation or timeout. If human-help tools are disabled, stop and tell the user what is needed instead of repeatedly attempting the blocked action.
Does local MCP mean local-only model processing?
No. It describes the browser connection. The external host may use a remote model. Floatboat can use the corresponding manual MCP path after setup, but that is not upstream certification, a bundled model, or a claim that this page tested the reader’s installation.