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. If the current version provides page logs or network information, use them to investigate further.
5. After changing code, reload the page and recheck the original issue.

Preview a local development page

The browser pane is suited to the short loop of “open the page, exercise a key control, reload, and verify again.” It can help you check:

• whether the page opens from the current development server;
• whether routes, tabs, and form inputs behave as expected;
• whether a narrow desktop or mobile viewport introduces overflow, overlap, or hidden content;
• whether a code change preserves the intended page state after reload.

Do not treat a reachable local page as a public deployment. localhost only means that the service is available on the current computer; sharing it with other people requires separate deployment or external access configuration.

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

Browser identity determines which login state EvoX uses. Open Settings > Cowork > Browser to choose EvoX's own browser or Take over my everyday Chrome.

• The dedicated browser stores data separately; sign in directly inside it when needed.
• Everyday Chrome mode depends on Playwright Extension and reuses existing logins, cookies, and tab state.
• The first everyday-Chrome task requires choosing Allow on Chrome's connection page; one-time authorization is available when the extension credential can be read.
• Turning off one-time authorization stops silent connection, but full revocation requires regenerating the token in the extension.
• Before clearing browsing data, confirm that another task is not still using it.

See Use everyday Chrome for installation, authorization, and revocation.

Site permissions

When EvoX reads a page, enters content, or navigates to another site, a site-permission prompt may appear. 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

Currently confirmed features:

• 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.

The following features can vary by EvoX version, operating system, or browser environment:

• page logs, network request details, console output, printing, downloads, and developer tools;
• multiple browser profiles, persistent login, and cookie import;
• 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

1. Start the project development server and confirm that the browser pane discovers the correct localhost entry.
2. Open the target route in a desktop viewport and check the first screen, navigation, and key controls.
3. Switch to a mobile viewport and check overflow, overlap, wrapping, and touch-target size.
4. Exercise one key flow, then reload and confirm that the resulting state is sensible.
5. If the current version provides logs or network information, use them to distinguish page problems from browser feature limitations.
6. Recheck site permissions, login state, and temporary cookies against the task scope.
7. Record the observed result for downloads, printing, developer tools, and cross-platform differences instead of replacing verification with “should work.”

EvoX Docs · Features · Capabilities