Skip to content
OneviumDocs
On this page

Browser automation: page checks, forms, and screenshots

Use Onevium’s built-in browser or Chrome to inspect pages, test forms, and capture screenshots. Configure login state and verify approvals and results.

What the browser helps you do#

Ask the assistant to open pages, check forms, interact with controls, and explain results using screenshots, console messages, and network observations.

The current @Browser guidance targets Control Chrome. For the native browser, send a message explicitly asking to use Onevium's built-in browser, with the URL and task, then verify the actual target. Use Settings → Browser to manage configuration.

Confirm the page and account first#

Use a preview site and test account. A local service must listen on the correct port; an existing terminal process does not prove readiness. Check it with managed services if needed.

Confirm the URL, tab, and account. Do not assume an external Chrome login automatically appears inside Onevium. Sign in within the intended browser context. Page content used by the assistant may be sent to the configured model.

Choose Native, External, or Auto#

Open Settings → Browser, turn on AI browser control, then choose Browser to control. Fresh installations start with AI browser control off. Upgrades preserve an existing enabled setting; check the displayed switch rather than assuming every installation has the same default:

ChoiceWhen to use itRequirement
NativeDefault backend once enabled; keep page work beside the conversationNo Chrome extension or claude --chrome required
ExternalYou explicitly need an external Chrome control environmentA working external connection; configure Control Chrome on the same page
AutoChoose based on availabilityPrefers native, falls back to external; still verify the actual target

The choice affects the next browser call. Turning the master switch off hides AI browser-control entry points; it does not clear cookies.

For external Chrome, check extension installation, the Control Chrome switch, and connection state on the same page. Wait for readiness, then send a small request in a new conversation to confirm which browser is controlled.

Profiles: management and limitations#

Settings → Browser → Profiles lets you create a profile, import cookies from detected browsers, and delete non-default profiles. Profiles provide separate site-data storage.

Regular conversations currently have no visible Profile selector, and default browser calls still use the default profile. Creating a profile does not automatically switch the current or next conversation or establish account isolation between tasks.

Previews using the same browser profile can share cookies and login state. Separate conversation tab tracking is not account isolation. After importing cookies, open the target site and verify the account. Clear browsing data can sign several tabs out of their shared partition; do not use it as the first troubleshooting step.

Import cookies without leaving the current page

  1. Open the native tab's toolbar menu and choose Cookies & browser settings.
  2. Use Import Cookies, check the detected source browser/profile, and import the intended login data. This dialog targets the current tab's browser profile.
  3. After the import completes, use its refresh action and check the target site's account name before continuing.

A successful cookie count does not prove the website accepted the login. Tabs sharing this profile may share the updated session. If detection or import fails, retain the error and sign in within the intended browser instead of importing unrelated profiles.

Find a page from this conversation

Once a conversation has used the browser, use the globe button beside permissions to revisit its pages:

  1. Open the history list and search by page title or URL.
  2. Scroll to load more records when the page is not in the first group.
  3. Select a record to reopen the page, then verify its current URL and account before continuing.

The bottom of the conversation information panel also has a collapsible browsing-history section with a record count. History is saved per conversation; it helps you return to a task's pages without combining every conversation's list. It is not a separate login profile or a saved copy of the page, and reopening a URL does not restore its earlier contents.

First task: check a form#

  1. Open Settings → Browser, enable AI browser control, and select Native. If Settings → Tools also lists a Browser group, check that it is enabled.
  2. Return to a demo project and send a normal message asking to use Onevium's built-in browser, with the exact preview URL and a request to describe the page first. Do not substitute the external-Chrome tag for that target instruction.
  3. Confirm the page and account, then send a bounded task:
text
Check the test site's invitation form with an empty and invalid email.
Do not send invitations or change roles.
Record visible messages, screenshots, and relevant console/network errors.
Stop and report if you reach production or a real account.
  1. Inspect elements again after navigation or updates, and reconfirm the target when switching tabs.
  2. Handle required approvals according to permissions, then inspect the report.

Read-only scripts that extract page text, titles, or tables normally run without repeated confirmation. Clicks that submit, send, or delete, and keys such as Enter that may submit a form, can still require approval. Full Access does not remove these browser confirmations.

The confirmation card identifies the website and action. Expand Show script when you need to inspect the code, then approve the intended action. Do not increase permissions just to read a page.

Confirm the check is complete#

The report should identify the URL, scenario, expected and observed results, and evidence. A screenshot only proves what was visible at that moment; HTTP success alone does not prove correct form or permission behavior.

Unavailable pages, missing accounts, and unperformed actions are “not tested,” not “passed.” Remove tokens, personal information, and sensitive request data before sharing.

Narrow layouts and default viewport#

Choose a common preset in Settings → Browser → Default viewport for new tabs. Existing tabs can adjust their viewport through the toolbar menu.

For example, open a test invitation form, use the toolbar menu's viewport control to choose a phone preset, and check that the email field, validation message, and submit button remain reachable. A viewport larger than the panel can be inspected by scrolling horizontally and vertically.

Page zoom is a separate control in the same menu: use minus/plus to change it, or click the percentage to return to 100%. Keep zoom at 100% when comparing viewport presets so you know which change caused the layout difference. Changing the current tab's viewport does not rewrite the default for new tabs.

Check whether buttons, validation, and navigation actually work at narrow widths. A size preset is not real-device acceptance and does not prove matching touch input, browser identity, or device behavior. Complete unavailable checks in the target browser or on a real device.

Common problems#

  • Missing entry: check the applicable version at the top of this page and the browser master switch. If Settings → Tools lists a Browser group, confirm it is enabled.
  • Blank page: inspect URL, port, console, and network rather than repeatedly refreshing.
  • Wrong account: verify the actual browser and profile; conversation names do not establish login isolation.
  • Stale element: read the current page before selecting a control.
  • External connection failure: check the extension and connection state, retry, and verify a small task.

Next steps#

Use the Browser reference, prepare previews with managed services, and set task boundaries with permissions.