cdp-toolkit 1.7.0 → 1.9.0

package/CHANGELOG.md

@@ -5,6 +5,407 @@ All notable changes to cdp-toolkit are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.9.0] - 2026-08-09
+
+Four complaints from a field agent driving an MV3 extension, closed without adding
+a tool: the surface grows inside `evaluate_script`, the `target` selector
+grammar, and error DX. Tool count stays 45. Two seats landed sequentially —
+W2 (`label:` + key-echo) first, W1 (worker targets + idle-wake) on top of it —
+and every protocol assertion below was probed against a live Chrome 151 before
+being built on, because five 1.8.0 premises were folklore that measured false.
+
+### Added
+
+- **`label:<name>` in the target-selector grammar, universal across every
+  page-taking tool.** Resolves an exact label match against BOTH the origin
+  ledger (tabs this toolkit created) and live lease records (a tab taken over
+  and claimed with a label, which has no origin record) — so a tab you named
+  is findable by that name regardless of which path put you in it. A miss
+  enumerates the labels that DO exist, deduped across both sources; an
+  ambiguity (the same label on two live targets) names both ids rather than
+  silently picking the first. **The grammar turned out to have three
+  independent copies** — `pickPage` (`src/shared-tools.ts`), `pickTarget`
+  (`src/client.ts`, the one `evaluate_script`/`click`/`hover`/… actually call),
+  and `pickContext` (`src/bidi/driver.ts`, Firefox) — a fact the live smoke
+  caught immediately when `label:` worked in `claim_page` but not in
+  `evaluate_script`. The lookup core is now one function, `resolveLiveLabel`
+  in `src/origins.ts`, wired into all three call sites, each keeping its own
+  error class. A new structural test, `test/manifest-grammar-drift.test.ts`,
+  asserts every manifest description that names `title:` also names `label:`,
+  so a fourth resolver copy (or a stale description) can't slip past review
+  silently again.
+
+- **Key-echo validation on `evaluate_script`.** When `expression` is missing
+  or empty and the call instead carries `function`, `code`, `js`, `script`,
+  `fn`, or `body`, the error names the wrong key by value and says the right
+  one is `expression` — and, when the value looks like a function literal,
+  that function literals go in `expression` with `args`. One line, saving the
+  round trip the field complaint measured.
+
+- **`evaluate_script` can now evaluate inside an MV3 extension's background
+  SERVICE WORKER, not just a page — no raw-CDP escape hatch needed.** Pass
+  `target: "worker:<extension-id>"` (or any substring of the worker's url,
+  e.g. `worker:background.js`) and read `chrome.storage.local`,
+  `chrome.runtime`, and the worker's own globals directly. Chrome-only
+  (capability `worker.targets`) and accepted by `evaluate_script` alone —
+  `worker:` is deliberately absent from `pickPage`'s page-only grammar
+  (closing/selecting/releasing a worker is meaningless) and refused there by
+  name, and a new drift-test arm asserts no OTHER tool's manifest description
+  ever names `worker:<`, so a later sweep can't advertise a Chrome-only,
+  one-tool selector as universal grammar. Firefox refuses the arm with a
+  capability-gap error naming `worker.targets`, per ADR-001 — WebDriver BiDi
+  has no extension-service-worker target concept to map onto.
+  **`wake` (default `true`)** asks Chrome to start the worker first when the
+  selector matches nothing or a known-but-stopped worker, then re-resolves;
+  `wake:false` fails fast with an error that teaches the MV3 eviction fact
+  instead of a bare "not found". Worker targets bypass the lease gate
+  entirely (`assertLeaseOk` is skipped for a worker-typed resolution in
+  `client.ts`): reap's "close the stale tab" is meaningless for a target
+  Chrome starts and stops on its own, and strict mode auto-acquiring a lease
+  per evaluate would mint a file keyed on an id that vanishes at the next
+  idle — garbage the page-only reap set can never collect. The page-only id
+  set reap and leases already keep (`ReapInput.livePageIds`) was left
+  unmerged on purpose.
+
+### Measured, not assumed — the protocol facts this release ships on
+
+Every one of these was a hypothesis in the spec and a measurement against a
+live Chrome 151.0.7922.109 before any line of feature code was written:
+
+- **`evaluate_script` against a worker never needs a flattened browser
+  session.** `/json/list` exposes a running service worker with its own
+  `webSocketDebuggerUrl`, and a direct WebSocket connect + `Runtime.evaluate`
+  with `awaitPromise` works there exactly as it does against a page — proven
+  by `self.constructor.name === "ServiceWorkerGlobalScope"` in the same
+  round trip. The feature rides the existing per-target connect path with no
+  new connection model.
+- **The "awaited value is lost over a flattened session" folklore is false on
+  Chrome 151, measured anyway even though it turned out not to matter.**
+  `Target.attachToTarget{flatten:true}` against the same worker returns the
+  real awaited value too. **No warning was shipped for a loss that cannot be
+  triggered.**
+- **A stopped MV3 worker is invisible to every target listing — `/json/list`
+  and `Target.getTargets` under any filter — so "no such worker" almost
+  always means "idle-evicted," not "wrong id."** The only place a stopped
+  worker is visible at all is the registration inventory
+  `ServiceWorker.enable` pushes as events, which is why the miss/wake error
+  text says so explicitly.
+- **`ServiceWorker.enable`/`startWorker` do not exist on the browser
+  endpoint** (`-32601 wasn't found`) — **they work on a flattened session over
+  any page**, including a plain `about:blank` tab with no relationship to the
+  extension. That's the wake mechanism: attach to whichever page target
+  happens to be open, enable the domain there, start the matched scope.
+- **`startWorker` reports empty success for a scope that does not exist at
+  all** — its return value is worthless as proof a worker woke. A wake is
+  therefore verified only by re-reading the target list until the worker
+  reappears (bounded, 30 × 300ms), never by the command's own result.
+- **`--load-extension` is inert on Chrome 151**, even with the documented
+  `--disable-features=DisableLoadExtensionCommandLineSwitch` unblock flag —
+  confirmed by checking the ServiceWorker registration inventory, which would
+  show a stopped-but-installed extension even if nothing were running, and
+  showed nothing at all. `Extensions.loadUnpacked` over CDP is the install
+  path that actually works, and is what the new extension smoke and any
+  future extension testing with this toolkit should use. `--headless=new` is
+  fine for driving an extension; no headed instance is required.
+
+### Notes
+
+- Tool count is unchanged at **45** — this release grew `evaluate_script` and
+  the target-selector grammar, not the tool list.
+- `docs/social-preview.html` and `docs/demo.tape` carry no version string and
+  needed no re-render for this release.
+- New tests: `test/label-selector.test.ts`, `test/worker-selector.test.ts`,
+  two new arms in `test/manifest-grammar-drift.test.ts` (inclusion for
+  `label:`, exclusion for `worker:`), and a new live smoke,
+  `test/extension-smoke.ts`, against a fixture MV3 extension in
+  `test/fixtures/mv3-extension/` — 20/20 assertions, including a genuine idle
+  eviction (worker absence from `/json/list` asserted before waking) and a
+  strict-mode check that a worker evaluate mints zero lease files while a
+  page evaluate in the same run still mints one.
+
+## [1.8.0] - 2026-08-09
+
+Two tracks land together, merged onto one integration branch. Track S closes the
+gap 1.7.0's takeover mode opened: an agent can now claim a human's open tab, but
+nothing detected the human was still there, and reap could destroy an
+agent-abandoned tab the moment it went idle. Track P is four groups of input
+parity chrome-devtools-mcp already had and this toolkit didn't: a wheel/scroll
+tool, a raw mouse primitive, real HTML5 drag-and-drop, and navigation
+history/downloads/permissions. Tool count moves 41 → 45. Every new
+input-dispatching path (Track P) was wired through Track S's dispatch log as
+part of the merge, not left as a follow-up — see "Changed" below.
+
+### Added
+
+- **An activity beacon: `claim_page` and `list_leases` now know when a human is
+  already using a tab (`src/activity.ts`).** A tiny in-page script records the
+  timestamp of the last `pointerdown`/`mousedown`/`keydown`/`wheel`/`touchstart`,
+  installed at claim time on both `claim_page` modes and
+  `new_page{claim:true}`. On Chrome, `Page.addScriptToEvaluateOnNewDocument`
+  alone does **not** survive navigation under this toolkit's per-call connection
+  lifetime — the registration dies with the connection that made it, which is
+  every tool call, a fact verified against a live browser before anything was
+  built on it (`addScriptToEvaluateOnNewDocument` → new connection → navigate →
+  `null`). So the CDP driver now holds one connection open per beaconed tab
+  purely to keep the registration alive across navigations, bounded at 32
+  tabs with oldest-first eviction; an evicted tab still answers for input on
+  its current document, only the next navigation's re-arm is lost. Firefox
+  needs none of this — its BiDi session lives for the whole process, so a
+  `script.addPreloadScript` registration survives navigation for free, and was
+  implemented and live-verified rather than left absent, since the spec's
+  Firefox carve-out only applied if the plumbing was intractable and it wasn't.
+  CDP-dispatched input is `isTrusted:true` too, so the beacon alone cannot tell
+  a human click from the toolkit's own: every input-dispatching call writes to
+  an in-process dispatch log, and a beacon timestamp counts as human only when
+  it postdates this server's last dispatch on that tab by more than 1500ms.
+  `claim_page`/`list_leases` surface it as `humanActiveMs` — milliseconds since
+  input this server did not dispatch. **`null`/absent means NO DATA, never "no
+  human"**: a fresh tab, a tab whose every input was this server's own, and a
+  backend that cannot answer at all are all indistinguishable from each other
+  and from silence. A `claim_page` takeover of a tab a human used within the
+  last 30 seconds additionally carries a `contention` warning string, and **the
+  claim is never refused for it** — taking over a person's tab is what
+  takeover mode is for, so the warning informs a caller who already holds the
+  lease, it does not gate anything. Known blind spots, stated rather than
+  designed away: input inside a cross-origin iframe is invisible to the
+  beacon, and a *second* MCP server process's dispatches read as human to this
+  one, since dispatch-log correlation is scoped to this process.
+
+- **Split reap horizon: reclaimable and destroyed are different moments, now
+  separated by `CDP_REAP_GRACE_MS`.** Before this release, `list_pages` and
+  `list_leases` closed an agent's tab the instant its lease read `expired`,
+  which is also the instant another agent becomes *entitled* to take it —
+  fine for handing the lease to someone else, destructive when applied to the
+  tab itself. An agent 20 minutes into a build between tool calls does not
+  expect to come back to a destroyed tab just because it could, in principle,
+  have been reclaimed. `staleAgentTabs` (`src/reap.ts`) stays a pure function
+  but now takes `now`/`reapGraceMs`: an `expired` lease qualifies for the
+  destructive close only once `now - lastUsedAt > ttlMs + reapGraceMs`.
+  `CDP_REAP_GRACE_MS` defaults to `2700000` (45 minutes), for a 60-minute total
+  fuse after last use. Lease *reclaimability* — `list_leases`' `stale` field —
+  is byte-for-byte unchanged at `ttlMs`; only the destructive close moved.
+  `dead-pid` is unaffected by grace and reaps immediately, because that
+  process is never coming back and there is nothing to wait for.
+
+- **Renderer ping and lease observability on `list_pages`/`list_leases`.**
+  `list_pages` gains `probe?: boolean` (default false, byte-identical shape
+  when omitted): one bounded (500ms) `Runtime.evaluate` per page-type target,
+  run concurrently so one wedged tab cannot stall the rest of the listing
+  beyond its own budget. Adds `responsive: boolean` (false on a timeout, a
+  page-side exception, or an unreachable target — never an error for the
+  whole call) and, where the same round trip finds human-attributed input,
+  `humanActiveMs`, reusing the beacon's own discrimination rule rather than a
+  second implementation of it. Separately and unconditional on `probe`,
+  `list_leases` rows gain computed `idleMs` (now−lastUsedAt) and `expiresAt`
+  (lastUsedAt+ttlMs, the same value `claim_page` already returns under that
+  name), and `list_pages` entries for a tab under an active, readable lease of
+  the driver's own backend gain `lease: {label,pid,idleMs,expiresAt,stale}`.
+  Both are computed fresh in the tool layer on every call, never stored.
+
+- **`scroll`, a new wheel-dispatch tool, on both backends.** Anchor at
+  `uid`/`selector`/`x`+`y` (element anchors are scrolled into view first, same
+  as `click`), or the viewport center if all three are omitted; at least one
+  of `deltaX`/`deltaY` is required, positive `deltaY` scrolling down and
+  positive `deltaX` scrolling right (wheel convention). Chrome dispatches
+  `Input.dispatchMouseEvent{type:"mouseWheel"}`; Firefox dispatches WebDriver
+  BiDi's `wheel` input source — both live-verified against a real browser, not
+  left on "it typechecks." A real bug surfaced along the way: Chrome
+  smooth-scrolls a wheel dispatch, so the command's ack resolves once the
+  event is *queued*, not once the resulting scroll has *settled*, and a
+  caller reading `scrollTop` immediately after could see the pre-scroll
+  value. Fixed with a capture-phase `scroll` listener armed before dispatch
+  (window-level, since `scroll` doesn't bubble but a capture-phase listener on
+  `window` still sees it), debounced 60ms with a 500ms hard cap rather than a
+  blind sleep sized wrong for both large and small deltas.
+
+- **`dispatch_mouse`, the raw move/down/up primitive, Chrome-only.** Dispatch
+  exactly one `move`/`down`/`up` mouse event at absolute viewport coordinates
+  (`x`/`y` required on every call — CDP has no notion of a current pointer
+  position to default from); compose your own move/down/move/up sequences for
+  anything a physical mouse can do that `click`/`drag`'s fixed sequences
+  can't — canvas drag-painting, marquee/rubber-band selection, a custom
+  hit-testing widget. Takes the same `button`/`clickCount`/`modifiers` as
+  `click`. Lives outside the Driver abstraction by design, alongside
+  `heap.ts`/`screencast.ts`'s other chrome-only-tool modules, but is
+  lease-gated through the exact same choke point every other interaction tool
+  uses. Chrome-only, capability `input.raw`: absent from `tools/list` under
+  `--browser firefox`, never present-and-throwing.
+
+- **`click` gains `modifiers` and `clickCount:3`.** `modifiers` (Alt/Control/
+  Meta/Shift, CDP bits 1/2/4/8) is held for both press and release, e.g.
+  `["Shift"]` for a shift-click; `clickCount:3` triple-clicks, selecting a
+  paragraph/line in most editors. `modifiers` is a **Chrome-only parameter on
+  an otherwise-universal tool**: a non-empty array throws a clear error under
+  `--browser firefox` rather than being silently dropped or ignored — a
+  documented param-level gap under ADR-001, not a missing tool.
+
+- **Real HTML5 drag-and-drop (`drag mode:"html5"`), plus `steps`, `to:{x,y}`,
+  and `by:{dx,dy}` on the existing mouse-mode drag.** The spec's premise —
+  that synthetic mouse events cannot drive HTML5 drag-and-drop at all — is
+  **false**, measured against Chrome 151: `mode:"mouse"` (the default) does
+  start a real drag and can fire `dragstart`/`dragover`/`drop`. The actual gap
+  is that *which* `dragover` events reach the page depends on where the
+  interpolated pointer path happens to land, because mouse mode's drag
+  events follow that path rather than being dispatched at fixed points. At
+  the default `steps:2`, a drop zone written the standard way (`preventDefault`
+  only inside `dragover`, the HTML spec's own pattern) sees **zero** `dragover`
+  events and refuses the drop outright — a coin flip decided by geometry, not
+  a reliable "it doesn't work." `mode:"html5"` closes that gap deterministically:
+  `Input.setInterceptDrags(true)` arms interception, the mouse press/move
+  sequence runs, `Input.dragIntercepted` hands back the page's own `dragstart`
+  DragData, and the toolkit replays it as `dragEnter`→`dragOver`→`drop` exactly
+  at the destination — path-independent, and interception is always disabled
+  in a `finally`. Missing the intercepted event within 5 seconds (e.g. the
+  source isn't `draggable="true"`) is an actionable error, never a silent
+  no-op. `mode:"html5"` is Chrome-only (capability `input.html5Drag`, absent
+  from `REQUIRED_CAPABILITIES` so `drag` itself stays available on both
+  backends) and is rejected with a clear error under Firefox rather than
+  silently downgrading to mouse mode, which would report a drop that never
+  happened. `steps` (default 2, matching the exact pre-1.8.0 dispatch) sets
+  the interpolated-move count for mouse mode; `to` now also accepts an
+  absolute `{x,y}` alongside `uid`/`selector`, and a new top-level `by:{dx,dy}`
+  offsets from the source point instead (sliders, map panning, resize
+  handles) — exactly one of `to`/`by` is required, refused rather than
+  resolved by precedence when both or neither are given.
+
+- **`navigate_page` gains `history: "back"|"forward"`, on both backends.**
+  Traverses this tab's session history like the browser's own Back/Forward
+  buttons: Chrome via `Page.getNavigationHistory` + `Page.navigateToHistoryEntry`,
+  Firefox via BiDi's `browsingContext.traverseHistory{delta:±1}`. Mutually
+  exclusive with `url`/`reload` — passing two of the three is refused by name,
+  never resolved by precedence. Going back from the first entry, or forward
+  from the last, is an **error naming the direction**, never a silent
+  no-op that navigates nowhere; both backends were made to raise the same
+  sentence (Firefox's own error never names a direction, so the BiDi driver
+  rewraps it). Waits for the same load milestone as an ordinary navigation.
+
+- **`wait_for_download`, capture a real file download as a file on disk,
+  Chrome-only and MCP-server-only.** Returns `{path,suggestedFilename,bytes,
+  url,target}`, renaming Chrome's internal guid to the page's own filename
+  (collision-suffixed: `report.csv`, `report-1.csv`, ...). Two premises in the
+  original design were probed against a real browser before anything was
+  built, and both were **false**: `Browser.setDownloadBehavior` does **not**
+  persist past the arming client's disconnect (measured: an armed-then-closed
+  connection followed by a click landed zero files, no events, anywhere — the
+  download is *denied*, not merely misdirected), and the toolkit's per-call
+  CDP lifetime means every tool call is exactly such a disconnect. The fix is
+  `src/tools/browser-session.ts`: one lazily-opened, module-scoped connection
+  to the browser endpoint, held open for the process's life, arming download
+  capture once and keeping a ring buffer of completions — opened only when
+  `wait_for_download` or `grant_permissions` is first called, so a session
+  that never downloads pays nothing. **Ordering rule, not optional:** call
+  `wait_for_download{arm:true}` *before* the click that starts the download
+  (it arms and returns immediately: `{armed:true,downloadPath,pending}`), then
+  click, then call `wait_for_download` again to collect the finished file —
+  arming late loses the download with no file anywhere to recover it from.
+  **Browser-global side effect:** while armed, *every* download in the
+  browser, all tabs and origins, is redirected into the toolkit's downloads
+  directory for as long as the server runs. **MCP-server only, not a
+  preference:** the arm lives on a connection this server process holds open;
+  under the one-shot CLI that connection dies with the process before a
+  download could ever complete, so the tool needs the long-lived server the
+  same way `performance_start_trace`/`start_screen_recording` already do.
+  Chrome-only, capability `browser.downloads`: WebDriver BiDi has no command
+  to redirect a download to a chosen directory.
+
+- **`grant_permissions`, pre-answer permission prompts for an origin,
+  Chrome-only and MCP-server-only.** `permissions: string[]` takes CDP
+  PermissionType values (`geolocation`, `notifications`, `clipboardReadWrite`,
+  `camera`, `microphone`, `midi`, ...; an unknown name is refused by Chrome
+  with the bad value in the message), keyed by **origin**, not tab — every
+  tab on that origin is affected, including ones opened later. `reset:true`
+  clears this server's previous grants first, or instead when no permissions
+  are given; CDP's reset is not itself origin-scoped, so it clears every
+  origin at once. The same probe that falsified `wait_for_download`'s
+  persistence assumption was run against `Browser.grantPermissions` on
+  spec, since the same per-connection-state trap applies here too, and it
+  sprang: a grant also does **not** survive the granting client's disconnect.
+  Shares `browser-session.ts`'s standing connection with `wait_for_download`
+  for exactly that reason. Chrome-only, capability `browser.permissions`:
+  absent from `tools/list` under Firefox, never present-and-throwing.
+
+### Changed (behavior, no flag)
+
+- **Every input-dispatching path, old and new, now writes through one choke
+  point, closing a real bug the individual branches could not see.** Track P
+  was built against pre-1.8.0 main, before Track S's dispatch log existed, so
+  its `scroll` and html5-drag paths sent `Input.*` straight down the
+  connection. Merged as-is, this compiles, typechecks, and passes both
+  branches' full test suites while the activity beacon reports the toolkit's
+  own scroll as a human using the tab — an agent warned about contention with
+  itself, the exact failure the beacon exists to prevent, invisible to either
+  branch's own tests because neither branch could see the other's code.
+  `dispatch_mouse` lives outside the Driver abstraction and has no
+  `dispatchInput` to call, so the write moved to a new shared function,
+  `sendInput(conn, backend, targetId, method, params)` in `src/activity.ts`;
+  `CdpPageDriver.dispatchInput` now delegates to it and `dispatch-mouse.ts`
+  calls it directly. `Input.setInterceptDrags` (html5 drag's arm and its
+  `finally`) is sent but deliberately **not** recorded: it synthesizes no
+  page input, and logging it would suppress a real human input landing in the
+  same 1500ms window — classified by denylist, so an `Input.*` command nobody
+  thought to classify defaults to being logged, because over-warning is
+  recoverable and silent misattribution is the bug this feature exists to
+  avoid. Firefox needed no code change: Track P built its BiDi scroll and drag
+  on `performActions`, which already called `recordDispatch`, so it inherited
+  the log for free — the whole argument for having a choke point in the first
+  place. The invariant — nothing in `src/` sends `Input.*` except through
+  `sendInput` — is grep-verified post-merge and is now also a test
+  (`test/input-dispatch-wiring.test.ts`), mutation-checked by reverting
+  `scroll` to a raw send and confirming the test names the exact line and the
+  live smoke reproduces the bug (`humanActiveMs=202` on the toolkit's own
+  scroll, instead of `undefined`).
+
+### Residuals
+
+- **A stale claim in `drag`'s own manifest description was caught and fixed
+  during integration, not by a fresh reader later.** An earlier pass on the
+  top-level `drag` description already stated the measured mouse-vs-html5
+  finding, but the `mode` property's own enum description still read "does
+  nothing on HTML5 draggable elements" — the exact folklore the rest of this
+  release measured false. Corrected to match; no test pinned the stale
+  string.
+- **Second-MCP-server blind spot, stated plainly.** Two MCP server processes
+  driving the same browser cannot see each other's dispatch logs, so one
+  server's tool calls read as human activity to the other. Accepted: the
+  discrimination rule is honest about what it can and cannot see, and the
+  alternative (a shared dispatch log across processes) is a much larger
+  feature for a scenario this toolkit does not otherwise support (see
+  "Parallel tabs" — one writer per flow).
+- **Cross-origin iframe input is invisible to the beacon,** since the
+  listener is installed on the top document only. Under-warning here is the
+  same accepted direction as the denylist above: a missed human input reads
+  as agent-only, never the reverse.
+- **`dispatch_mouse`'s `modifiers` and `click`'s `modifiers` are two separate
+  parameters that happen to share an enum,** not one modifier system: each
+  tool validates and documents its own Firefox behavior independently.
+- **Firefox's BiDi `scroll` path shipped once and was verified twice, in two
+  different seats.** It typechecked and passed unit tests against the real
+  BiDi capability set when Track P landed, but no Firefox was available to
+  that seat to run it live; the integration seat had one, ran it, and it
+  passed unmodified — the implementation was correct the first time, only the
+  live evidence was missing. Recorded here so "typechecks" is never mistaken
+  for "verified" on the next capability that ships without a live check.
+
+### Notes
+
+- Tool count is now 45 (29 parity + 16 superset: `performance_trace`, the
+  cookie group, the network-mocking group, the lease group, the
+  screen-recording pair, `scroll`, `dispatch_mouse`, `wait_for_download`, and
+  `grant_permissions`); 34 under Firefox, which lacks the eleven
+  capability-gated tools — the pre-1.8.0 eight (tracing, heap-snapshot,
+  Lighthouse, screen-recording) plus `dispatch_mouse`, `wait_for_download`,
+  and `grant_permissions`. `scroll` and the extended `navigate_page`/`click`/
+  `drag` params ship on both backends; only `click`'s `modifiers` and `drag`'s
+  `mode:"html5"` stay Chrome-only, and only at the parameter level — the
+  tools themselves are universal.
+- Two new live-smoke scripts, `bun run staleness:smoke` and `bun run
+  input:smoke`, are each a single process talking to a single browser:
+  `CDP_BASE` is a module-level constant captured at import time, so one
+  process cannot address two browsers on two ports. Each is therefore
+  env-driven — `staleness:smoke` honors `STALENESS_SMOKE_PORT` (default
+  9501), `input:smoke` honors `CDP_SMOKE_PORT` (default 9513) — so the two
+  can run against separate scratch Chromes without colliding.
+
 ## [1.7.0] - 2026-08-09
 
 Four things land on top of 1.2's opt-in lease model, all under one new switch
@@ -469,6 +870,8 @@ First public release.
 - Zero runtime dependencies in the CDP/CLI layer (Node's global `WebSocket` + `fetch`). The MCP server adds only `@modelcontextprotocol/sdk`; `lighthouse_audit` is the sole non-CDP tool and shells out to `npx lighthouse`.
 - Runtime: Bun ≥ 1.1 (recommended) or Node ≥ 22 (for the global `WebSocket`). Requires Chrome/Chromium started with `--remote-debugging-port=9222`.
 
+[1.9.0]: https://github.com/sblattj/cdp-toolkit/releases/tag/v1.9.0
+[1.8.0]: https://github.com/sblattj/cdp-toolkit/releases/tag/v1.8.0
 [1.7.0]: https://github.com/sblattj/cdp-toolkit/releases/tag/v1.7.0
 [1.6.0]: https://github.com/sblattj/cdp-toolkit/releases/tag/v1.6.0
 [1.0.0]: https://github.com/sblattj/cdp-toolkit/releases/tag/v1.0.0

package/CONTRACT.md

@@ -18,6 +18,12 @@ writing a module.
 
    **`claim_page{target}` is a deliberate, reviewed exception to this rule, not a violation of it.** Its target resolution goes through `pickPage` (`src/shared-tools.ts`), which is exported *specifically* for this one caller and does **not** call `assertLeaseOk`. Routing a claim through `resolvePage` instead would, under strict mode, auto-acquire a lease on the way in and then collide with the explicit claim right behind it, one call claiming the same tab against itself twice. The protection is not dropped, only relocated one layer down: `claimLease`'s own conflict check still refuses a tab any live process holds, auto-acquired or explicit, so a stranger's tab is still refused, only later and by a different function. `pickPage` must never gain a second caller without re-deriving this argument for that caller too; if it does not need gate-free resolution, it needs `resolvePage`, not `pickPage`.
 
+   **A worker-typed hit inside `resolveTarget` is the other deliberate exception, added in 1.9.0.** A `worker:<substring>` selector (Chrome only, capability `worker.targets`, `evaluate_script`'s alone) resolves to a service/shared worker target, and `resolveTarget` returns it before reaching `assertLeaseOk` — see the comment at the top of that branch in `src/client.ts`. A lease answers "who is driving this tab"; a worker is not a tab, has no reap-meaningful close, and strict-mode auto-acquire on it would mint a lease file keyed on an id that vanishes the moment Chrome idles the worker out, garbage the page-only reap set (`ReapInput.livePageIds`) can never collect. This also cannot be used to bypass a lease on an actual tab: there is no tab a worker resolution could stand in for.
+
+   **The `TargetSelector` grammar itself also has three independent copies, a separate fact from the lease choke points above** — `pickTarget` (`src/client.ts`, what `resolveTarget` calls, and what most tools reach through), `pickPage` (`src/shared-tools.ts`), and `pickContext` (`src/bidi/driver.ts`, Firefox). A prefix arm added to one does not exist for callers routed through another; `label:` (1.9.0) was first wired into only `pickPage` and passed every unit test while `evaluate_script` still rejected it, because `evaluate_script` calls `pickTarget`, not `pickPage`, and only the live smoke caught the gap. The shared lookup core for an arm that needs identical semantics everywhere (as `label:` does) belongs in its own module — see `resolveLiveLabel` in `src/origins.ts` — wired into all three call sites, each keeping its own error class (`CdpError` / `SharedToolError` / `DriverError`). `test/manifest-grammar-drift.test.ts` structurally asserts a completeness property (every `title:` mention also mentions `label:`) and, separately, an exclusion property for `worker:` (no tool other than `evaluate_script` may name it) — grep `startsWith("title:")` across `src/` before adding a new arm, and extend or scope that test for it.
+
+7. **Never dispatch `Input.*` outside `sendInput`.** As of 1.8.0 there is exactly one function that writes a synthesized input command to a Chrome connection: `sendInput(conn, backend, targetId, method, params)` in `src/activity.ts`. `CdpPageDriver.dispatchInput` (the per-driver choke point every interaction method already had to go through) delegates to it, and any tool built outside the Driver abstraction (`dispatch_mouse`, in `src/tools/dispatch-mouse.ts`, is the precedent) must call it directly rather than opening its own `conn.send("Input....", ...)`. This is what keeps the activity beacon's human/agent discrimination (`src/activity.ts`'s dispatch log) correct: a new input path that bypasses `sendInput` will typecheck, pass its own unit tests, and pass `bun test` in full, while silently making the toolkit's own input read as a human using the tab — exactly the 1.8.0 merge bug `test/input-dispatch-wiring.test.ts` now exists to catch (it walks every `.ts` under `src/`, strips comment-only lines, and fails on any line that both sends and names `Input.`). On the Firefox side, `BidiPageDriver.performActions` is the twin choke point and already calls `recordDispatch`; a new BiDi input path goes through it the same way `CdpPageDriver.dispatchInput` is used on Chrome. Mode-toggle commands that dispatch no page input themselves (`Input.setInterceptDrags`'s arm/disarm around HTML5 drag) are still sent through `sendInput` but are on a denylist that skips recording them — classify a new such command explicitly; the default for anything unclassified is to be logged, since over-warning a human is recoverable and silently misattributing their input to "agent" is not.
+
 ## Core client API (from `src/client.ts`)
 
 ```ts
@@ -67,7 +73,9 @@ export async function click(args: ClickArgs): Promise<unknown>;
 - Recorder buffers: `${ARTIFACT_DIR}/rec-<targetId>.jsonl`.
 - Screencast spool: `${ARTIFACT_DIR}/screencast-<targetIdShort>-<isoish>/` holding `frame-NNNNNN.jpg|png` plus the generated `frames.ffconcat`. Deleted on a successful encode; **kept, and named in the error, when ffmpeg fails**, so the frames can be re-encoded by hand instead of lost. Output video: `${ARTIFACT_DIR}/screen-recording-<targetIdShort>-<isoish>.mp4`.
 - Lease files: `${ARTIFACT_DIR}/lease-<backend>-<targetId>.json`, one per leased tab, backend is `chrome` or `firefox`. Written with the `wx` exclusive-create flag so two simultaneous claims cannot both win. Keyed by backend plus id because a CDP targetId and a BiDi context id are not disjoint by construction. Carries an `auto?: boolean` field (absent, and read as `false`, on any record older than 1.7.0): `true` means the gate itself acquired it under `CDP_REQUIRE_LEASE` and it is usable by any call from the owning pid with no token; `false` means it was claimed explicitly (`claim_page` or `new_page{claim:true}`) and demands its token even from that same pid.
-- Origin files (`src/origins.ts`): `${ARTIFACT_DIR}/origin-<backend>-<targetId>.json`, one per tab this toolkit itself created (never written for a tab merely claimed). Same exclusive-create discipline as lease files, same directory, and it deliberately OUTLIVES the lease: `release_page`, expiry, and reclamation never touch it, only the tab closing does (reaped on the next `list_pages`/`list_origins` read). This is what `release_page` and reap both consult to decide whether closing a given tab is this toolkit's call to make; see `src/reap.ts`'s header for the four conditions that gate a reap close.
+- Origin files (`src/origins.ts`): `${ARTIFACT_DIR}/origin-<backend>-<targetId>.json`, one per tab this toolkit itself created (never written for a tab merely claimed). Same exclusive-create discipline as lease files, same directory, and it deliberately OUTLIVES the lease: `release_page`, expiry, and reclamation never touch it, only the tab closing does (reaped on the next `list_pages`/`list_origins` read). This is what `release_page` and reap both consult to decide whether closing a given tab is this toolkit's call to make; see `src/reap.ts`'s header for the four conditions that gate a reap close. As of 1.8.0 an `expired` lease qualifies for that close only past `ttlMs + CDP_REAP_GRACE_MS` (default 45 extra minutes) — `list_leases`' `stale`/reclaimable reading is unchanged at `ttlMs`; only the destructive close moved later. `dead-pid` is unaffected by grace.
+- Beacon sessions (`src/activity.ts`, `src/cdp/driver.ts`): a `BeaconSessions` pool of held Chrome connections, one per tab with an installed activity beacon, bounded at 32 with oldest-first eviction — the same module-scope pattern `recorder.ts`/`network_mock.ts` already use for their own persistent per-target sessions. Exists only because `Page.addScriptToEvaluateOnNewDocument`'s registration dies with the connection that made it (verified against a live browser, not assumed), so surviving navigation under this toolkit's per-call lifetime requires holding a connection open; eviction degrades (the current document's listeners keep answering, only the next navigation's re-arm is lost) rather than breaking. Firefox needs no equivalent: its `LifetimeModel` is `"session"`, so a `script.addPreloadScript` registration on the one memoized BiDi connection per port already lives as long as that connection does.
+- The browser-session connection (`src/tools/browser-session.ts`): one lazily-opened, module-scoped connection to the CDP browser endpoint (not a page endpoint), held open for the process's life, backing `wait_for_download` and `grant_permissions`. Opened only on first use of either tool, so a session that never touches downloads or permissions pays nothing. Exists because `Browser.setDownloadBehavior` and `Browser.grantPermissions` were measured — probed against a real browser before either tool was written — to NOT persist past the arming/granting client's disconnect, which this toolkit's per-call connection lifetime would otherwise hit on every single call. Both tools are therefore MCP-server-only capabilities, the same category as `performance_start_trace`/`stop_screen_recording`'s persistent-connection requirement, for the same underlying reason.
 
 ## The element-reference scheme (READ if you touch snapshot or input)