Limit JavaScript Access for Browser Coding Agents

An agent investigating a browser problem may only need to read page structure, inspect errors, and capture a screenshot. Giving it JavaScript evaluation adds more power than those tasks always require. Chrome DevTools MCP now provides controls for restricting evaluation, including --no-javascript-evaluation. That can help teams separate inspection from actions that may change the page. It does not replace rules for signed-in accounts, form submissions, or production changes. I would start each investigation with the access needed to observe the failure, then add a capability only when the next debugging step requires it.

Separate page inspection from JavaScript evaluation

Many debugging tasks only require observation: inspect markup, list console messages, read network metadata, compare styles, or capture a screenshot. JavaScript evaluation is powerful because it can change page state, read accessible data, trigger application code, and make requests with the current session.

If a tool can solve the task without that capability, disabling it reduces accidental and malicious paths. The same principle applies to filesystem roots and command execution: grant what the current investigation needs, not what the tool could theoretically use.

Use care with signed-in browser sessions

A development browser may hold admin sessions, customer tools, cloud dashboards, and extensions. An agent connected to that browser can inherit more authority than the repository itself. A prompt injection in page content can then become an instruction aimed at a privileged runtime.

I prefer dedicated browser profiles, synthetic accounts, staging data, and restrictions on which domains the agent may access. Execution controls add another layer; they do not replace safe session design.

Grant access for the task being investigated

I would begin read-only: navigate to the known test URL, capture the DOM and screenshot, inspect messages, and identify a narrow hypothesis. If evaluation is required, I would enable it for the smallest step and record what code will run.

Form submissions, content changes, purchases, deletes, and account actions remain separate approvals. A JavaScript console can perform real actions when it is attached to an authenticated application.

Record enough evidence to reproduce the result

The same release adds on-demand source maps, heap-snapshot queries, PWA lifecycle tools, and richer console stack traces. These help agents gather evidence without loading every expensive artifact or guessing from a surface error.

I care less about an agent producing a fast answer than about it producing a reproducible trail: exact URL, browser version, observed state, controlled action, and before-and-after result.

Write a short browser-agent policy

• Use a dedicated test profile and synthetic accounts.
• Start with JavaScript evaluation disabled.
• Restrict filesystem roots and target domains.
• Keep production mutations outside ordinary debugging.
• Capture the page state that justified each action.
• Expire tokens and sessions after the work.
• Review new agent plugins like executable dependencies.

The policy should be short enough that developers actually follow it and specific enough that exceptions are visible.

Review the controls available in the tool

The Chrome DevTools October update also mentions configurable paths and modular agent plugins. Those capabilities make the tool more useful, but they also require explicit access rules.

I see the JavaScript switch as a healthy direction: give automation the ability to prove what it needs before giving it the ability to act.

Review plugins and record tool versions

The update also supports modular Agent Plugins. I would review one of these packages the way I review executable development dependencies: who publishes it, what version is pinned, which tools it registers, which paths and network destinations it can reach, and how updates are approved. Convenience is not a substitute for provenance.

Teams should keep the browser toolchain reproducible. Record the Chrome and DevTools MCP versions, committed configuration, permitted roots, and plugin inventory alongside the test project. If an agent suddenly behaves differently, those versions become part of the bug report. I would also separate broadly reusable read-only plugins from task-specific packages that can mutate state. A plugin can make an agent more capable, but it should not quietly widen every session. Load tools because the current task needs them, and remove that access when the task ends.

There is also a practical debugging benefit to starting read-only: it preserves the failure. Executing a helper script can change timing, storage, focus, or application state and make an intermittent defect disappear. Capturing the untouched DOM, console, network, and screenshot first gives the investigation a baseline that later actions cannot recreate exactly.

When evaluation is enabled, I prefer a small named snippet that can be reviewed and rerun over an improvised chain of expressions. The code, target page, expected return value, and possible side effects belong in the task record. That makes the powerful step legible to the next developer.

Make limited access the default

Save a browser-agent configuration that supports routine inspection with limited access, and document how developers request additional capabilities. Use a dedicated test profile where possible. Before running code, record the target page, the intended result, and possible side effects. Keep permission for a content change or external action separate from permission to debug. A short, usable policy makes it easier for the team to choose appropriate access without rebuilding the rules for every investigation.

Photo by Markus Spiske on Pexels.