Specialized / Front-end debugging

Press Alt+Shift+C, click an element, write what should change, and press Enter. chrome-use sends your words, the element's source file and line, a screenshot and its styles through ocs to the Claude Code, Codex or Pi session already working on that project, and that agent edits the code. It works on local dev servers and on test-environment domains, in the Chrome you are already logged in to.

Getting started

1. Install chrome-use and the extension (extension 0.5.56 or later, CLI 1.5.213 or later).
2. Install ocs and keep a Claude Code, Codex or Pi session open in the project folder. Without ocs the panel shows the install command and keeps your draft.
3. Press Alt+Shift+C on the page, or click Inspect element in the toolbar popup. The first time it asks you to enable the feature. Change the shortcut at chrome://extensions/shortcuts.
4. Click an element. Shift+click or drag a box to select several (up to 8); ↑/↓ move to the parent or child; P pauses page animations so moving things are easy to hit; Esc exits.
5. Write the change in the panel. Each element can carry its own note, and you can draw on its screenshot. Enter or Send sends; Shift+Enter adds a line.

The first send on a site asks two things: which project folder the site belongs to, and which session gets the request. Candidates come from the local dev server's process folder, the working folders of ocs sessions, and which projects actually contain the source files the page names. The choice is remembered per site. Review or remove bindings in the Inspect & Ask card of the extension options.

Source locations: add code-inspector-plugin

To show file:line, the project marks its DOM at build time. chrome-use reads the data-insp-path attribute that code-inspector-plugin adds; it supports Vite, webpack, Rspack, esbuild and Turbopack, with React, Vue, Svelte and more. When a page has no marks, the panel lists the exact changes and asks whether your agent should make them. Or add it yourself:

// vite.config.ts
import { codeInspectorPlugin } from 'code-inspector-plugin';

export default defineConfig({
  plugins: [
    codeInspectorPlugin({ bundler: 'vite', pathType: 'relative' }),
    // ...your other plugins
  ],
});

// webpack.config.js / vue.config.js (configureWebpack)
const { codeInspectorPlugin } = require('code-inspector-plugin');

module.exports = {
  plugins: [codeInspectorPlugin({ bundler: 'webpack', pathType: 'relative' })],
};

Without the plugin it still works: React 18 and earlier dev builds expose a component's source location, and Vue dev builds expose the component file. When neither is there, the message says "no source location" and carries the selector and text so the agent can search. React 19 removed per-component source locations, so React 19 projects should add the plugin.

In our tests, code-inspector-plugin 2.0.9 builds carry absolute paths in the marks (on a test environment, paths from the CI machine). chrome-use matches them by path suffix inside the project folder you bound, labels such matches "matched by path suffix", marks the rest unverified, and never searches outside that folder.

Test environments

Test-environment pages work too, as long as the test build keeps the marks. The plugin only runs in development by default, so turn it on explicitly for test builds. Never for production: with marks on, anyone who can open the test environment can read source file paths in the page.

// Test builds only, never production. DEPLOY_ENV is whatever your CI sets.
const isTestBuild = process.env.DEPLOY_ENV === 'test';

codeInspectorPlugin({
  bundler: 'vite',
  pathType: 'relative',
  dev: () => process.env.NODE_ENV === 'development' || isTestBuild,
  server: isTestBuild ? 'close' : 'open',
});

// index.html of the test build: lets the agent compare revisions
<meta name="chrome-use-revision" content="%GIT_SHA%">

# a production build must contain no source marks
$ grep -rl "data-insp-path" dist/ && echo "FOUND: do not ship" || echo "clean"

A test environment may run older code than your local branch. When the page carries chrome-use-revision, the message includes it and tells the agent to check local files and treat line numbers as approximate. The revision comes from the page too, so it is only a hint, never an authorization.

Sending and status

The panel reports what ocs actually returned, with storage and wake kept apart:

The full context (each element's HTML, styles and screenshot) is written to ~/.chrome-use/inspect/ctx/<id>/, readable only by you and removed after 7 days (only the batch id and its outcome stay, so a batch is never sent twice); the ocs message carries a summary and that path. Without ocs, or when you do not want to deliver, Copy puts the same content on the clipboard as Markdown, and Open in editor opens the file at the line in VS Code, Cursor, Windsurf or WebStorm.

Safety boundaries

• The page is touched only when you press the shortcut or the button. Nothing stays in pages, and no "started debugging this browser" bar appears.
• Page text, HTML, component names and source paths are untrusted data, labelled apart from your words, and they never choose the project or the session.
• The input box runs in the extension's own frame, so page scripts cannot read or change what you type. The frame proves itself with a one-time secret; a copy made by the page never gets it.
• Every send re-checks that the panel is fully visible; a covered, faded or moved panel does not send. This lowers the risk of UI deception without guaranteeing against it.
• Screenshots are attached only when the page is the visible tab and nothing changed during capture; otherwise they are dropped with a reason. Your tabs are never switched for you.
• Delivery never raises the receiving session's permissions and never starts an agent for you.

How it differs

code-inspector-plugin's AI mode, React Grab, Agentation, MCP Pointer and Cursor's Design Mode also hand a clicked element to AI. Most are limited to a local dev server, or start their own agent process and deliver through the clipboard or a local MCP endpoint. Inspect & Ask works in your logged-in Chrome, on test environments too, and sends to the session you already run, without a new process and without loosening permissions.

Troubleshooting