Chrome Gave Coding Agents a JavaScript Kill Switch. I Think That Matters.

Chrome’s October DevTools update includes fine-grained JavaScript execution controls for coding agents, including a mode that lets an agent inspect a page without evaluating scripts. That may sound like a small command-line option, but I think it expresses an important security idea: browser access is not one permission. Reading the DOM, taking a screenshot, executing JavaScript, reading local files, submitting a form, and navigating into a signed-in system have different consequences. Tools become easier to trust when those actions can be granted separately.

Inspection and execution should not be synonyms

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.

Signed-in browsers raise the stakes

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 domain boundaries. Execution controls add another layer; they do not replace safe session design.

Permission should follow the debugging phase

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 is not a harmless microscope when it is attached to an authenticated application.

Performance controls also improve evidence

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.

My minimum 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.

Better tools should produce smaller trust assumptions

The Chrome DevTools October update also mentions configurable paths and modular agent plugins. Those capabilities make the tool more useful, but they make the permission model more important as well.

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.

Plugins extend the trust boundary again

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. Capabilities should be loaded because the current task needs them and removed 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.

My default browser session is read-only

I would add a read-only browser-agent configuration to the project alongside a documented escalation path for evaluation and writes. The goal is not to remove useful automation. It is to make the default debugging session incapable of changing more than the task requires.

Photo by Markus Spiske on Pexels.