A web app can pass its unit tests and still fail the first time someone uses it. The button is below the fold. The form error is invisible to a keyboard user. A route works when loaded directly but breaks after client-side navigation. These are browser problems, not just code problems. GitHub Copilot browser tools in VS Code are now generally available, and the official announcement describes an agent that can navigate pages, click, type, read content, inspect console errors, and capture screenshots. That turns browser verification into a repeatable part of the coding loop.
What the browser agent adds
Traditional tests answer questions about functions and components. A browser agent can answer questions about the running application: did the page load, did the interaction change the right state, did the console stay clean, and did the visible result match the request? The VS Code browser testing guide uses a small calculator as an example, but the same pattern works for a dashboard, checkout flow, settings page, or authenticated internal tool.
- Navigation: open the local app and move between routes.
- Interaction: click, type, hover, drag, and handle dialogs.
- Observation: read page content, capture screenshots, and inspect console output.
- Scripting: run a short Playwright sequence when many steps are easier to express as one flow.
The useful loop is build, test, inspect, fix
The value is not that an agent can click a button. The value is that the agent can use the running page as evidence while it is making the change. Give it one outcome, ask it to exercise the path, and make it report what it saw before it edits more files.
Build and verify this flow:
1. Start the app and open /settings.
2. Confirm the page heading and the Save button are visible.
3. Change the notification setting.
4. Submit the form.
5. Confirm the success message appears.
6. Check the browser console for errors.
7. Take a screenshot of the final state.
8. If a step fails, explain the observed state before changing code.That prompt has two properties worth keeping. It names a user-visible outcome rather than prescribing an implementation, and it asks for evidence at the end. The agent can choose the selectors and sequence, but you still get a concrete report of what happened.
Start with one happy path
Do not ask for a full end-to-end audit as the first request. Pick one path that matters to a user and make it pass. A focused flow gives the agent a clear stopping point and gives you a useful failure if something is wrong. Once the path is stable, add the validation cases that have caused real bugs.
Good first flows
- Sign in and reach the first authenticated page.
- Create an item and confirm it appears in the list.
- Submit an invalid form and confirm the error is visible.
- Open the mobile navigation and follow one link.
- Change a setting, reload the page, and confirm it persisted.Keep credentials and destructive actions out of the first pass. Use seeded test accounts, local fixtures, and a test environment. If a flow sends email, charges a card, deletes data, or changes production configuration, the agent should not have permission to perform it just because the browser can.
Understand which browser state the agent can see
Pages opened by the agent run in private, in-memory browser sessions by default. They do not share cookies or storage with your everyday tabs. That is a good default for local testing, but it also means the agent will not automatically be signed in to the account you use in another browser window. The VS Code context documentation explains that you can explicitly share an existing browser page with the agent when a test needs that session. Treat sharing as an explicit access decision, especially if the page contains personal or production data.
Use the console as a second signal
A screenshot can look fine while the browser is reporting a failed request, hydration warning, or uncaught exception. Ask the agent to inspect console output after the interaction, not only after the initial page load. Then ask it to connect the error to the step that triggered it. This keeps the debugging conversation tied to a user action instead of turning into a list of unrelated warnings.
When a flow fails, report:
- The URL and visible heading
- The action that was attempted
- The visible result
- The console errors and warnings
- The failed network request, if one is visible
- The smallest likely code path to inspect
- Whether the failure is reproducible after a reloadSet boundaries before you make the agent autonomous
Browser tools are powerful because they let the agent act. That is also why you should decide what it can reach before turning on a long-running workflow. VS Code supports an organization-managed browser tools setting, plus network filtering through allowed and denied domain lists. Denied domains take precedence, and when filtering is enabled with both lists empty, agent network access is blocked. See the AI settings reference for the current setting names and policy behavior.
{
"chat.agent.networkFilter": true,
"chat.agent.allowedNetworkDomains": [
"localhost",
"127.0.0.1",
"api.example.test"
],
"chat.agent.deniedNetworkDomains": [
"*.production.example.com"
]
}Treat this as an illustrative policy shape, not a drop-in policy for every organization. Confirm the setting names and your enterprise deployment method in the current VS Code documentation. The important design is the boundary: allow the test environment and required APIs, then deny the production domain even if a broad rule would otherwise match it.
Keep human review in the loop
A passing browser flow is evidence, not a release approval. The agent may click the wrong element, misunderstand a page, miss an accessibility issue, or report a warning that is unrelated to the real failure. VS Code's trust and safety guidance recommends reviewing generated changes and being careful with tools that can access files, run commands, or call external services.
- Read the diff before accepting a fix.
- Run the normal unit, integration, and end-to-end checks as well.
- Check that the test data and browser session were the ones you intended.
- Treat screenshots and console output as review evidence that another person can inspect.
A browser test worth keeping
The best browser-agent test is small enough to run after every meaningful UI change and specific enough to catch a real regression. Start it from a user outcome, keep it inside a safe test environment, ask for visible and console evidence, and make the agent explain failures before it edits. The result is not magic browser automation. It is a tighter feedback loop between the code you change and the experience you intended to ship.