| Age | Commit message (Collapse) | Author |
|---|
|
|
|
merge by title
|
|
evaluate/snapshot/waitFor/initScript
- evaluateInTab/executeInTab now run through CDP Runtime.evaluate instead of
new Function() in MAIN world, so chrome_evaluate/chrome_snapshot work on pages
that block unsafe-eval (github.com, many bank/SaaS apps). Preserves value
markers (undefined/function/symbol/bigint/Error), DOMRect expansion, and the
expression/statement fallback; keeps {ok,value} error envelope.
- page.waitFor polls via service-worker-side CDP evaluation.
- chrome_navigate initScript uses Page.addScriptToEvaluateOnNewDocument.
- Add npm test (test-suite/unit/csp-eval.test.mjs) and in-browser regression
challenge 42 strict-csp-evaluate; update challenge 39 notes + docs/primer.
|
|
DOMRect serialization, stale-target errors, pageMutated wording
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Defer all pi.registerTool() calls until /chrome authorize fires.
Previously, 18 chrome_* tool definitions + chrome-profile-bridge
primer consumed ~5K tokens/turn even when Chrome control locked.
Changes:
- Add chromeToolsRegistered flag (default false)
- Wrap all pi.registerTool() calls in registerChromeTools(pi)
- Only register tools when authorizeFor() runs
- Make before_agent_start conditional: primer injected only when
tools registered AND authorized
- No tools exist in context until user explicitly allows it
Saves ~5,000 tokens/turn when Chrome control is locked.
|
|
- Remove startup notification about companion extension
- Remove static 'Chrome bridge :17318' status bar entry
- Add updateChromeStatus() helper: shows green dot + 'Chrome Bridge'
only when authorized, clears otherwise
- Call from session_start, authorizeFor, revokeHandler
|
|
Adds an early-capture script injected at document_start on every
navigation via webNavigation.onCommitted + injectImmediately:true.
Wraps console.*, fetch, and XMLHttpRequest before page JS runs, so
console messages, errors, unhandled rejections, and network requests
during page load are captured in window.__PI_CHROME_STATE__.
Sets __piChromeWrapped flags so the existing post-hoc
installPiChromeInstrumentation() is idempotent (checks instrumentationInstalled).
Fixes chrome_list_console_messages returning empty for errors
that fire during React render / initial API calls.
|
|
Tree-equivalent to v0.15.20 (preceded by the revert commit). Bumping
to 0.15.21 sets the package up for normal patch releases on the 0.15.x
line going forward — no version-number collisions with the unpublished
0.16/0.17 work.
|
|
Reverts the pairing + signed-envelopes work (0.16.0-0.16.1), the
standalone daemon refactor (0.17.0-0.17.3), and assorted patches.
These were unpublished from npm; this commit restores the working
tree to match the v0.15.20 release so the branch tip and the npm
'latest' dist-tag are consistent again.
Tags v0.16.0 through v0.17.3 are preserved as recovery anchors;
the work is reachable via 'git checkout v0.17.3' if ever needed.
Tree-equivalent to v0.15.20.
|
|
In 0.17.x the daemon is a separate process that can idle-shut-down
(10 min idle) or be killed externally while Pi sessions are running.
Without self-heal, the next /chrome onboard or chrome_* call surfaces
'fetch failed' instead of recovering.
bridge.admin() now catches the failed fetch, re-runs ensureDaemonRunning
(probe -> spawn if missing), and retries once.
bridge.sendViaOwner() pre-probes /status and spawns the daemon if missing
before issuing the signed /command.
Net effect: a missing daemon transparently respawns instead of bubbling
fetch failed up to the user.
|
|
Bugs surfaced in real-world 0.17.0/0.17.1 testing:
1. Daemon /next only recorded lastSeenAt AFTER the auth/pair checks. Pre-pair
the daemon returns needsPairing early without recording the poll, so
connected stayed false even though the extension was polling. /chrome
onboard's wait-for-poll loop spun forever on a healthy extension.
Fix: record lastSeenAt at the top of /next for any chrome-extension
origin, before auth checks. Onboard now correctly detects 'extension
alive but unpaired' which is the precise state during pair step.
2. Daemon compatibility was checked at major.minor match. Result: a patch
release fixing a daemon bug (like #1) couldn't replace the running
daemon — new Pi client joins old buggy daemon as client.
Fix: exact version match. Patch releases auto-kill+respawn the daemon.
|
|
0.17.0 made the daemon own the HTTP listener, but the Pi client's
bridge.status().connected still reflected the local Pi's lastSeenAt
(which is never updated in the daemon model). Onboard's connect-wait
loop spun forever even when the extension was polling the daemon.
Fix: new ChromeProfileBridge.daemonStatus() async helper that fetches
the daemon's /status. onboard, doctor, and status now query that for
the 'connected' flag instead of reading stale Pi-side state.
|
|
The Chrome bridge is now a separate detached daemon at
~/.cache/pi-chrome/<version>/daemon.cjs. Every Pi session is a uniform client;
daemon lifecycle is decoupled from any Pi session. Killing a Pi never breaks
Chrome control, and pi update followed by any new Pi session auto-replaces
an incompatible daemon.
Architecture:
- New extensions/chrome-profile-bridge/daemon.cjs: ~700 LOC, zero deps, runs
detached. Owns the HTTP listener, BridgeAuth state, command queue, /pair
handshake. Idle-shuts-down after 10 min of no activity.
- ChromeProfileBridge on Pi side becomes a pure client: start() probes /status,
spawns daemon if missing/incompatible, kills+respawns if version mismatch.
send() always uses signed /command. No more server-mode branch.
- New signed /admin RPC for pair-window/reset/status state mutations the
daemon owns. Pi clients sign with broker key (same contract as /command).
- New /heartbeat for daemon idle-timer keepalive.
- daemon.log at ~/.cache/pi-chrome/<version>/daemon.log.
/chrome pair, /chrome unpair, /chrome onboard now go through /admin RPCs
instead of mutating in-process bridge state.
Removed the foreign-owner takeover dance from /chrome onboard (auto-handled
at session_start now).
Wire protocol is byte-identical to 0.16.x; existing paired extensions don't
need to re-pair. See docs/DESIGN-0.17-daemon.md for the full write-up.
|
|
User pain: machines stuck in broken state after pi-chrome upgrades because an old
pi-chrome process kept holding :17318 and /chrome onboard trusted confirm() clicks
without verifying anything. Both fixed.
Idempotent /chrome onboard recovery flow:
- Always resets Pi-side pairing state first (kills half-paired ghosts).
- Step 1 covers both first-install AND v0.15->v0.16 reload (extension service worker
must reload to gain the /pair logic).
- Actively verifies progress at each step rather than trusting clicks:
- polls bridge.status().connected (15s window) to confirm the extension polls /next,
- polls bridge.bridgeAuth.paired to confirm the /pair handshake completed,
- round-trips a real tab.version command to confirm the signed-envelope path works.
- /chrome install is now an alias of /chrome onboard.
Automatic stale-owner takeover at bridge.start():
- /status now includes bridgeVersion.
- On EADDRINUSE, probe /status with 1s timeout. If unresponsive OR major.minor
mismatches, locate the owner PID via lsof and kill it (SIGTERM -> SIGKILL),
then re-bind. Same-version owners are joined as clients (multi-Pi sharing).
- Eliminates the 'stale Pi session holding bridge' class of bugs that broke
upgrades from 0.15.x.
/chrome status / doctor / onboard no longer hang:
- New probeExtension() short-circuits before bridge.send when the bridge can't
round-trip (unpaired, or extension hasn't polled recently). Returns immediately
with an actionable message instead of waiting 5-35s.
|
|
Major security hardening of the Chrome bridge driven by red-team findings.
- Mandatory pairing via /chrome onboard (one-time per machine). Bridge pins exact
chrome-extension:// origin and derives HMAC keys via HKDF. Until paired, the
bridge returns idle responses and refuses to deliver commands.
- Signed envelopes on /next, /result, /command. HMAC-SHA256 over protocol version,
direction, method, path, extension ID, bridge ID, timestamp, fresh nonce, and
SHA-256 of the body. +/-30s clock window; 5-min LRU nonce replay defense on
both request and response directions; constant-time MAC compare.
- Peer Pi sessions sharing the bridge sign each /command with a broker HKDF key
(no bearer token transmitted) and verify the owner's signed response.
- Global loopback enforcement. PI_CHROME_BRIDGE_HOST=0.0.0.0 ignored unless
PI_CHROME_BRIDGE_DANGEROUS_REMOTE=1; loopback check still applies per-endpoint.
- Cross-process state coherence: fs.watch + per-request mtime check on
~/.config/pi/chrome-bridge.json. A peer Pi's unpair (or any external rm/edit)
propagates to the owner's in-memory state before the next privileged verify;
replay caches reset on key rotation.
- Body cap 1 MiB -> 413. Queue/pending/waiter caps. Malformed JSON -> 400.
Non-object JSON bodies -> 400 instead of being trusted.
- page.navigate initScript: try/finally around tabs.update, per-call onCommitted
listener with bounded commit-wait window, one-shot delete in global onCommitted.
No more stale init scripts firing on later unrelated navigations.
- crypto.randomUUID() command IDs.
- Manifest diet (dropped activeTab); added popup.html/popup.js for the pair UI.
UX:
- /chrome onboard runs install + pair in one interactive flow.
- /chrome help reorganized into First-time / Day-to-day / Maintenance.
- Status bar lights up as green dot only when authorized.
- Early console/network capture at document_start so boot-time React errors and
initial API calls aren't dropped (ported from DaniBedz/pi-chrome fork).
Docs:
- SECURITY.md threat model rewritten with in-scope / out-of-scope sections.
- README rewritten with the install-then-pair flow front and center.
- CHANGELOG 0.16.0 entry with full patch list.
|
|
Thread the harness AbortSignal through authorizedBridgeSend, the
ChromeProfileBridge send/sendLocal/sendViaOwner paths, and every
chrome_* tool's execute(). Pressing Esc now rejects the in-flight
bridge call immediately (most visibly fixing chrome_wait_for, which
would otherwise block for the full timeoutMs).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
table, section reorder
|
|
- Primer teaches agents the trusted:true escape hatch for CSP-locked pages
(github.com, banks, many SaaS) where chrome_evaluate/chrome_snapshot throw
EvalError due to missing 'unsafe-eval'. Agents now self-escalate instead
of giving up and asking the user.
- Corrects stale primer claim that chrome_evaluate works without 'unsafe-eval'.
- scripts/sync-manifest-version.js wired to npm version + prepublishOnly
lifecycle hooks; kills the recurring browser-extension manifest version
drift (cf. 0.14.4, 0.14.8).
|
|
|
|
When a different Chrome extension (password manager, autofill popup,
etc.) anchors an overlay to the focused input, Chrome's CDP refuses
our Input.dispatchMouseEvent with 'Cannot access a chrome-extension://
URL of different extension'. The CDP target list shows the foreign
chrome-extension:// URL as type:'other' attached to the same tab.
New behaviour in cdp() wrapper:
1. On that specific error for any Input.* call, snapshot CDP targets
to identify the offending extension id and log it (foreign-ext-
detected event added to ring buffer).
2. Send Esc via Input.dispatchKeyEvent (key dispatch routes by focus,
not coordinates, so it bypasses the overlay) to dismiss the popup.
3. Retry the original Input.* call once.
4. If retry still fails, throw a clear error naming the foreign
extension id and listing three concrete workarounds: disable that
extension on the page, use Tab-to-focus instead of clicking, or
run /chrome quiet off.
|
|
attachDebugger now:
- Calls chrome.debugger.getTargets() first and force-detaches any stale
CDP session this extension already owns on the target tab before
attaching. Stale sessions (left over from SW reloads or sibling
detach failures) often surface on the next attach as 'Cannot access
a chrome-extension:// URL of different extension'.
- Retries up to two more times (180ms + 500ms) instead of once. The
500ms back-off lets Chrome's content-script registration drain on
fresh navigations.
- Records every attach event (attached, stale-target-found, attach-
failed, retry-failed) in a 20-entry ring buffer for inspection.
New diagnostic action 'trusted.debug' returns extension version,
trusted mode, attached tabs, the inspected tab's URL/status, current
chrome.debugger.getTargets() output, and the recent attach-event log.
Use to investigate when a specific URL refuses to attach.
|
|
enter=save)
Bare /chrome no longer opens a sequential picker. It now opens an inline
SettingsList from pi-tui with two rows:
Click realism auto / on / off
Quiet mode on / off
Up/Down navigate, Space or Enter cycles the value of the focused row,
Esc closes. Each row's description updates live to match the current
value, so users always see what the active setting means.
When the Chrome extension hasn't been granted the debugger permission
(real-looking clicks unavailable), the Click realism row stays locked
on its current value and the description points to the fix.
Direct subcommands unchanged:
/chrome status / doctor / onboard
/chrome clicks [auto|off|on|status] (no-args still cycles)
/chrome quiet [on|off|toggle|status] (no-args still toggles)
|
|
status header
Reorganises the /chrome command surface:
/chrome status - one-line snapshot of connection + click mode + quiet mode
/chrome doctor - full health check (unchanged)
/chrome onboard - install extension (unchanged)
/chrome clicks - cycles auto -> on -> off -> auto when called with no args.
Explicit args (auto|off|on|status) still work.
/chrome quiet - toggles on/off when called with no args.
Explicit args (on|off|toggle|status) still work.
Removes the nested 'settings' wrapper. /chrome settings background/trusted
still functions as a hidden legacy alias but is no longer advertised.
Bare /chrome opens a picker with a one-line status header and cycle-target
labels: 'clicks: auto -> switch to on' / 'quiet: off -> switch to on'. No
second picker; one keypress flips the setting.
Argument autocomplete now returns full-path values (e.g. 'clicks auto') so
pi-tui's whole-argument replacement applies correctly. Top-level suggestions
show clicks / quiet / status / doctor / onboard with descriptions.
User-visible names match the descriptive copy:
- 'trusted' -> 'clicks' (matches 'real-looking clicks' / 'quiet clicks')
- 'background' -> 'quiet' (matches 'quiet mode' / 'watch mode')
README + agent prompt primer + internal hint strings updated.
|
|
- 07 pointer-properties: pass force: 0.5 on every CDP mousePressed so
PointerEvent.pressure reports 0.5 for trusted clicks (was 0,
inconsistent with real mouse behaviour).
- 13 focus-order: after a CDP-driven click on a focusable target,
re-focus with focusVisible: false so :focus-visible matches pointer
focus semantics (CDP press leaves :focus-visible=true otherwise).
- 21 keyboard-modifiers: chrome.debugger.attach occasionally rejects
with 'Cannot access a chrome-extension:// URL of different
extension' immediately after navigation. attachDebugger now waits
180ms, verifies the tab URL isn't privileged, and retries once.
- 27 scroll-momentum + 28 intersection-visibility: replace gentle
~1.25%/step linear taper with a ramp-up (~15%) + geometric decay
(~12% drop/step). Sizes n adaptively so peak event stays ≲22px so
small visibility targets get low-ratio IO samples while a clear
momentum tail remains for decay-pattern detectors.
- trustedDrag mousePressed also gets force: 0.5 (consistency).
|
|
Replaces /chrome-doctor, /chrome-onboard, /chrome-background,
/chrome-trusted with a single /chrome command that takes subcommands:
/chrome doctor (was /chrome-doctor)
/chrome onboard (was /chrome-onboard)
/chrome settings background [on|off] (was /chrome-background)
/chrome settings trusted [auto|off|on|status] (was /chrome-trusted)
Running /chrome with no arguments opens a picker. Argument auto-
completion walks the tree (e.g. type '/chrome se<Tab>' to land on
'settings', then '/chrome settings t<Tab>' to land on 'trusted').
All user-visible references (notify messages, doctor output, agent
prompt primer, README) updated to the new paths.
|
|
/chrome-background, /chrome-onboard, README
Replaces remaining jargon in every user-facing string:
- /chrome-doctor: 'Local bridge: mode=server, url=...' -> 'This pi
session is running the Chrome connection for this machine.'
'EXTENSION VERSION MISMATCH ...' -> 'The Chrome companion extension
is on an old version (X); this pi-chrome is Y.'
'chrome_evaluate("1+1") = 2' -> 'pi-chrome can run code in the
active Chrome tab.'
'navigator.webdriver=true on current tab — site fingerprinting may
flag automation.' -> 'Your Chrome is reporting itself as automated
to websites. Some sites use this signal to block sign-ins or bot
checks.'
- /chrome-background description + notify: drops 'silent/background
mode', frames as 'quiet mode' vs 'watch mode'.
- /chrome-onboard: walks through the click-by-click steps instead of
saying 'Developer mode -> Load unpacked'.
- session_start notify: drops 'Chrome profile bridge'; says 'pi-chrome
connected' / 'waiting for the Chrome companion to connect'.
- README 'Trusted-input mode (CDP)' section rewritten as 'Click modes'
with plain prose explaining quiet vs real-looking clicks and when
each fails.
Tool descriptions (seen by the agent) keep precise terminology.
|
|
Banner is themed by the user's Chrome (dark mode → dark grey for many
users), not always yellow. Use 'banner' alone or quote the actual
banner text 'Pi Chrome Connector started debugging this browser'.
|
|
User-facing strings rewritten in layman's terms — no more 'CDP',
'isTrusted', 'user-activation gates', 'synthetic events', 'debugger
API'. /chrome-trusted picker now explains each mode by what users
actually experience: yellow banner, which sites work, when to use it.
/chrome-doctor reports 'Click mode' instead of 'Trusted-input mode'.
Tool descriptions (read by the agent) keep precise terminology.
|
|
lands
|
|
auto-recover
- chrome_tap tool: real browser-trusted touchstart/touchend via
Input.dispatchTouchEvent for sites that gate on TouchEvent (mobile-
first PWAs, swipe carousels). Always uses CDP; banner appears.
- trustedScroll: per-step delta capped at ~80px, n=6..60 steps with a
bell-shaped weight curve, 22-52ms sleep between events so IntersectionObserver and rAF samples get gradient updates (fixes
intersection-visibility / smooth-scroll tests).
- cdp() wrapper auto-detects stale debugger sessions (tab nav,
DevTools toggle, manual cancel) and re-attaches+retries once
instead of throwing 'Debugger is not attached'. Fixes intermittent
failures during automated test sweeps.
|
|
Connector
Trusted-input mode default flips from 'off' to 'auto':
- Synthetic events still run first for every chrome_* call.
- If a click produced no page change AND the target's label looks like a
user-activation-gated affordance (play/copy/share/sign-in/etc), or the
page just emitted NotAllowedError / 'transient activation required',
the call is silently retried via chrome.debugger (CDP).
- Typing auto-retries when the input value didn't change at all
(editor rejected synthetic input).
- Result carries autoRetried=true + autoRetryReason + syntheticAttempt
so callers / agents see the upgrade happened.
- Yellow debugger banner now appears only for the retry, not every call.
Companion extension renamed 'Pi Existing Chrome Profile Bridge' →
'Pi Chrome Connector' (manifest, action title, SW client name, README,
slash-command notify strings). One-time chrome://extensions reload
needed to pick up the new name; auto-reload mechanism handles the rest.
/chrome-doctor explains the active mode and what smart-retry does.
/chrome-trusted picker shows 'auto (current)' first; on-mode now warned
as 'banner permanently visible'.
chrome_click / chrome_type tool descriptions explain auto-retry.
|
|
- No-arg /chrome-trusted now shows ui.select picker with current mode +
tradeoff for each option (on/off/auto/status)
- First-time on transition asks ui.confirm with banner warning
- Permission missing emits a clear ui.notify with fix instructions
- Direct args (/chrome-trusted on|off|auto|status) still work
|
|
|
|
Add opt-in CDP path so chrome_* tools can dispatch browser-trusted input
(isTrusted=true, satisfies user-activation gates: clipboard, fullscreen,
file picker, autoplay). Default remains synthetic events; no behavior
change unless trusted mode is enabled.
Companion extension:
- new "debugger" permission in manifest (one-time re-approval prompt in
chrome://extensions on update)
- attach/detach lifecycle per tab with idle-detach (15s) and listener
for onDetach (incl. canceled_by_user)
- trustedClick / trustedHover / trustedType / trustedFill / trustedKey /
trustedScroll / trustedDrag use Input.dispatchMouseEvent +
Input.dispatchKeyEvent through chrome.debugger.sendCommand, reusing
humanized timing, in-rect coord variance, pointer continuity, Shift
chord for uppercase, per-key cadence
- trusted.mode / trusted.status bridge actions
Pi side:
- /chrome-trusted slash command (on / off / auto / status)
- trusted=true param on chrome_click, chrome_type, chrome_fill,
chrome_key, chrome_hover, chrome_drag, chrome_scroll
- /chrome-doctor probes chrome.debugger availability and reports current
trusted mode + attached tabs
- README documents trusted-input mode and tradeoffs
|
|
Bump 0.8.0 → 0.9.1.
Companion extension (service_worker.js):
- humanise pointer paths: easing Bezier-ish interpolation w/ wobble, 12–42
steps, 4–18 ms gaps; pointer position persisted across calls
- click point picked inside element rect, not dead center
- pointer events fill movementX/Y, screenX/Y, pressure (0.5 on down),
pointerId, width/height, tilt, composed
- click sequence: humanMoveTo → pointerdown → focus → 45–140 ms hold →
pointerup → mouseup → click
- per-character typing: keydown → keypress → beforeinput → value mutate
(or execCommand for contenteditable) → input → keyup, with 25–95 ms
hold + 35–140 ms inter-key; auto Shift chord for uppercase/symbols
- pressKeyInPage emits same cadence + handles printable insert / Backspace
- hoverPage: humanised path + 80–220 ms dwell
- dragPage: full HTML5 sequence (dragstart/drag/dragenter/dragover/
dragleave/drop/dragend) with shared DataTransfer + pointer continuity
- new scrollPage: wheel events with front-loaded momentum-shaped deltas
- self-reload on version drift: SW reads x-pi-chrome-version header,
reloads when older than pi-chrome
Pi side (index.ts):
- new chrome_scroll tool
- PI_CHROME_VERSION read from package.json (and re-read on every /next
so future bumps take effect without pi restart)
- /chrome-doctor escalates version mismatch to top-line ✗ error and
skips downstream capability probes when stale
- /next response carries x-pi-chrome-version header for SW self-heal
Test suite (test-suite/):
- 28 challenge pages each catching a different synthetic-event tell:
isTrusted, webdriver/fingerprint, mouse entropy/timing/coords,
pointer pressure/continuity, per-char cadence + framework invariants,
user activation, honeypots, focus order, wheel scroll, drag+
DataTransfer, contenteditable+Selection, paste/clipboard, native
select, hover dwell, React valueTracker, keyboard modifiers, touch
events, stack-trace fingerprint, viewport-edge clicks, mousemove
rate, scroll momentum, IntersectionObserver visibility
- shared _lib.js exposes window.__verdict + writes localStorage so
index.html dashboard aggregates results
- notes/bypass-ideas.md documents fixes still needed per challenge
|
|
|
|
|
