v0.4.1 — accessible-name snapshot labels

Snapshot labels now come from a real accessible-name computation instead of a placeholder/value guess.

What changed

labelFor() follows the HTML-AAM chain:

1. aria-labelledby
2. aria-label
3. associated <label> — both for= and encapsulation
4. title
5. placeholder

The value attribute names only input[type=submit|button|reset].

Before this, form controls with perfectly ordinary markup returned empty labels, so an agent could not tell one textbox from another:

	0.4.0	0.4.1
<label>Customer name: <input></label>	""	"Customer name:"
<label for=e><img alt="Email"></label><input id=e>	""	"Email"
<label>Search <input> <button>Go</button></label>	button "Go"	button "Go"

Behavior change — check your callers

Radios and checkboxes now report visible label text instead of their value attribute:

0.4.0:  {"role": "textbox", "label": "small"}
0.4.1:  {"role": "textbox", "label": "Small"}

They previously looked like they were reading labels. They were reading internal values. Anything matching on "small" or "bacon" needs to match "Small" or "Bacon".

Not included

Recursive ACCNAME computation, form-associated custom elements, and non-spec heuristics for names carried in preceding text or table cells. Tracked separately.

Form-associated custom elements are specifically blocked rather than unfinished: content scripts run in Chrome's isolated world and cannot see a custom-element registry the page defined in its main world. Closing it needs a main-world injection decision.

Install

npm install -g chrome-browser-control
npx -y chrome-browser-control setup

Publishing is manual. This project holds no CI publish credentials.

v0.4.0

Adds the optional CDP response-body tier (phase b of the CDP work), behind a deny-by-default origin allowlist. Also covers the trusted-input tier from the previous cycle, which had not yet been released.

Install

npm install -g chrome-browser-control
npx -y chrome-browser-control setup

Publishing is manual from a maintainer machine. There are no CI publish credentials.

New: response-body capture, opt-in and off by default

Three tools, usable only after cdp_attach:

• cdp_network_watch — enables the Network domain and keeps an in-memory index of metadata rows only. No body is read or stored.
• cdp_network_requests — returns that index.
• cdp_response_body — reads one body, for one request, on demand.

This narrows a previously blanket guarantee, deliberately and with controls attached:

• Deny by default. Body capture uses a second allowlist in the extension popup, separate from Allowed Origins. An empty list means no body is readable. * is not a valid entry — the wildcard that works for page actions does not work here.
• A restricted-category denylist wins unconditionally, even over an origin you listed explicitly.
• Nothing is buffered. Bodies are fetched one request at a time, never held.
• Binary bodies and oversize bodies are refused, never truncated.
• Best-effort masking of obvious token-shaped fields — not a guarantee. Treat any response body as if it contains credentials.
• Response headers, Set-Cookie, and request post data are never exposed, at any tier.
• Every successful read is recorded to an append-only metadata log at ~/.chrome-browser-control/, mode 0600. Body content is never written there. cbctl status surfaces the count.

The CDP tier may still send only an enumerated list of protocol methods, enforced in code. Fetch, Network.setRequestInterception, Network.continueInterceptedRequest, and Runtime.evaluate remain forbidden: this project reads traffic and never modifies it.

Also in this release

Trusted CDP input — cdp_attach / cdp_detach, with click, type, keypress and click_at routed through real input events while attached.

Known limitations

Response-body index invalidation across navigation is not unconditional in one narrow case. See the follow-up issue for the exact preconditions. Nothing there bypasses the body-capture allowlist.

Guidance

This is an opt-in debugging tier for deliberate, task-scoped use on origins you typed in yourself. It is not safe to switch on and leave on. Prompt injection is not mitigated by it, and anything read enters your session transcript permanently.

v0.3.1

Minor release: background-friendly navigate defaults and richer agent skill playbook.

Install

npm install -g chrome-browser-control
# or
npx -y chrome-browser-control setup

Reload the unpacked Chrome extension after upgrading so the navigate focus behavior is live.

Changes

• Navigate leaves focus alone by default (does not activate background tabs; does not deactivate the focused tab). Pass active: true only when the tab must become visible.
• Agent skill: When Not To Use + Stuck Mechanics with honest capability limits.
• Docs: minor release = patch bump for small changes; major release = minor bump on 0.x for large changes.

Notes

• Publish is manual; no CI publish credentials.
• The agent skill is not in the npm tarball — install from this repo (skills/chrome-browser-control/) or your global skills dirs.

v0.3.0 — iframe document targeting

Chrome Browser Control 0.3.0 adds safe, exact-document iframe control while keeping existing top-frame calls backward compatible.

Highlights:

• Discover operable same-origin and permitted cross-origin frame documents with list_frames.
• Pass documentId to DOM observation and action tools, including snapshot, click, type, scroll, query_elements, wait_for, and perform_actions.
• Keep snapshot refs document-scoped so iframe navigation or replacement cannot redirect an action to the wrong document.
• Return stable DOCUMENT_STALE, DOCUMENT_POLICY_DENIED, DOCUMENT_HOST_PERMISSION_DENIED, and DOCUMENT_UNSUPPORTED failures without unsafe fallback.
• Redact blocked and unsupported frame identity, and enforce Allowed Origins independently for each iframe URL.

Notes:

• Omitting documentId preserves top-frame behavior.
• navigate and screenshot remain tab-level operations.
• Iframe bounds use frameViewport coordinates and are not screenshot crop coordinates.
• Cross-origin iframe control requires that iframe origin in Allowed Origins.

Upgrade:
npm install -g chrome-browser-control@0.3.0
cbctl setup

After setup, reload the unpacked extension in Chrome. Restart the chrome_browser_control MCP host so it loads the updated tool schemas. browser_status should report 24 registered tools.

Verification:

• 216 automated tests passed.
• TypeScript and extension syntax build passed.
• Public npm artifact installed and ran successfully via npx.
• Compact snapshot benchmark reduction: 82.45%.

v0.1.0 — First public npm release

Summary

First public npm package for chrome-browser-control: an installable CLI (cbctl / chrome-browser-control) plus MCP adapter for local Chrome-profile browser control.

Install

npm install -g chrome-browser-control
cbctl setup
cbctl start
cbctl doctor

Or one-shot setup via npx:

npx -y chrome-browser-control setup

Common commands: cbctl setup | start | stop | status | doctor | mcp | mcp-config.

MCP hosts should use server key chrome_browser_control with command: cbctl and args: ["mcp"] (start the broker with cbctl start first; attach-only by default).

Publishing notes

• Manual maintainer publish only (see docs/publish-checklist.md).
• No CI publish-on-push and no long-lived NPM_TOKEN in GitHub for the default path.

Included in this release

• Merge of PR #6 (npm distribution prep) on main at fcda8b6.
• Package version 0.1.0 on the public npm registry.