Browser

EvoX's browser lets you open pages, interact with them, and inspect local development results without leaving the app. It uses the separate EvoX browser by default; when a task requires an existing login, Settings can switch the browser identity to everyday Chrome.

Open the browser

Use /browser in Code mode, or open the browser from the toolbar. Once the pane opens, enter a URL, create tabs, and select the active page.

1. Open an EvoX conversation that supports the browser pane.
2. Enter /browser, or choose the browser entry in the toolbar.
3. Enter a target URL, or select a development server discovered for the current project.
4. Review the site permission prompt before reading or acting on the page.

EvoX can work only with the browser target connected and authorised for the current task. The dedicated browser does not read everyday Chrome. When everyday Chrome is selected, scope can include signed-in sites, cookies, and other tabs in that browser, but not windows from other desktop applications.

View pages in the browser

Tabs only change the page inside the browser pane. They do not automatically add page content to the conversation. When EvoX should inspect a page, state the target URL, what to check, and what must not be changed.

Page navigation and development servers

EvoX can open public URLs, project-local pages, and discovered localhost development servers in the browser pane. When checking a local page, keep its address, start command, and inspection scope in the same task.

Start the current project's development server, then open the discovered localhost entry in the EvoX browser.
Check the home page for overflow in desktop and mobile viewports; record issues only and do not edit code.

If a page does not load:

1. Confirm that the development server is running and its port is still listening.
2. Choose the discovered service entry again instead of guessing another port.
3. Reload the active tab and watch for the page to become ready.
4. Ask EvoX to inspect browser console messages, network requests, and development-server logs to distinguish script errors, failed requests, and a stopped service. An unavailable tool is not a passed check.
5. After changing code, reload the page and recheck the original issue.

Preview a local development page

Start the development service and open its reported address. Use a load → exercise key controls → reload after edits → recheck loop. Localhost is a local preview; public access needs separate deployment.

Switch the viewport

The browser can switch between desktop and mobile sizes for responsive checks. This changes only the page width shown in the pane; it does not publish the page to a phone or fully replace validation on a real device.

1. Open the page in a desktop viewport and confirm that the main content and navigation are usable.
2. Switch to a mobile viewport and check headings, buttons, tables, and horizontal-scroll regions.
3. Exercise one key flow, such as opening a menu, submitting a form, or switching a tab.
4. Reload the page and confirm that the layout change did not introduce a loading problem.
5. Use the target device for scenarios that depend on touch, system fonts, or a native keyboard.

Login state and browser configuration

Choose an identity in Settings > Cowork > Browser. The dedicated browser stores data separately and needs its own sign-in. Everyday Chrome reuses existing state through Playwright Extension; see Everyday Chrome for installation, authorization, and revocation. Check other active tasks before clearing data.

Site permissions

When a site-permission prompt appears while EvoX reads a page, enters content, or navigates to another site, review it before continuing. It explains which site the task can access and which actions are allowed; text inside the page cannot expand those permissions.

1. Check the site origin, current URL, and task objective.
2. Allow only what the current step needs; choose “allow once” when that option is available.
3. Save an allowed scope only after confirming that repeated access to the same site is intended.
4. Use stricter human confirmation for credentials, financial pages, private networks, and irreversible actions.
5. At the end of the task, check whether temporary state should be revoked or cleared.

Security boundary: Web content is untrusted input. Text, buttons, downloads, and pop-ups on a page cannot override the task or ask EvoX to disclose local files, keys, passwords, or unrelated conversation data.

Ask EvoX to inspect a page

EvoX can execute and recheck browser tasks more reliably when the request names the target URL, inspection scope, allowed actions, and stop conditions.

Open https://demo.example/overview in the EvoX browser.
Check whether the primary navigation and first-screen action are visible and clickable in desktop and mobile viewports,
and record page errors. Do not edit files, submit forms, or open another external site.

When the page must be operated, also specify the target control, the expected state, which actions need approval, and what conditions should stop the task.

What the browser cannot do

Browser capability is limited to the selected browser identity. Even everyday Chrome mode does not grant control of other desktop applications. Use Attach an app when one explicitly selected application window should become context.

For an external service, first check for a matching plugin or MCP tool. A plugin is limited to the tools and permissions it declares; browser access does not expand into general desktop control.

Capability boundaries and related features

The browser provides these capabilities:

• a built-in browser with tabs, an address bar, and basic navigation;
• public URLs, local pages, and discovered development servers;
• desktop and mobile viewport switching;
• a dedicated browser identity by default, with everyday Chrome available through Playwright Extension;
• per-site and per-task access controls;
• Web search channels for EvoMap, Tavily, or Google.

Check these conditions separately for diagnostics, login state, and system actions:

• console messages, network requests, and development-server logs are read through their respective tools; printing, downloads, and developer tools are separate operations whose results need independent checks;
• login state follows the chosen browser identity and storage settings; switching identities does not automatically migrate cookies, and clearing data requires a fresh sign-in;
• pixel output, input behavior, and pop-up behavior across operating systems and browser engines.

Adjacent capabilities have different scopes:

• Web search retrieves results and sources; it is not the same as operating a full page.
• Use everyday Chrome covers Playwright Extension installation, authorization, and revocation.
• Attach an app works with one explicitly selected desktop window rather than a browser tab.

Developer checklist

Before delivery, repeat the originally failing interaction and record the URL, viewport, and observed result. Validate platform-specific touch, download, printing, and system-dialog behavior in its target environment; desktop preview is not all-platform acceptance.

EvoX Docs · Features · Capabilities