mcp_browser 0.1.3

mcp_browser: ^0.1.3 copied to clipboard

Added #

• ChromiumLauncher(userDataDir:) — caller-supplied persistent profile. When set, the launcher reuses the given Chrome profile instead of a throwaway temp dir, so a session the user already established (e.g. a completed Google login) is carried into the automated browser. The directory is treated as caller-owned: close() never deletes it. This is the trusted path for SSO-gated sites — reuse an already-authenticated session rather than performing a login inside an automation-controlled browser, which providers like Google block ("this browser may not be secure").
• ChromiumLauncher.attach(endpoint:) — CDP attach mode. Connects to an already-running Chrome exposing a debugging endpoint (ws://…/devtools/browser/<id>, or host:port / bare port resolved via /json/version) instead of spawning. The user starts their own Chrome with --remote-debugging-port=<port>, logs in normally (2FA / passkey), and the agent attaches to reuse that authenticated session.
• ChromiumProcess gains ownsProcess / ownsUserDataDir flags; process is now nullable (null in attach mode).

Changed #

• close() honors session ownership. It only kills the process when the launcher spawned it (ownsProcess) and only deletes the profile dir when it created the throwaway temp (ownsUserDataDir). Attach mode disconnects without killing the user's Chrome; a caller-supplied profile is never deleted — closing the prior catastrophic path where close() unconditionally delete(recursive: true)'d whatever userDataDir it held.
• OS-keychain hardening flags (--password-store=basic, --use-mock-keychain) are applied only to throwaway temp profiles. Forcing them on a real profile would make the user's existing encrypted cookies unreadable, defeating profile reuse.
• Public op surface (9 ops + auth) and the seal/replay chain (BrowserAuthProfile, BrowserRuntime.setAuth) unchanged — this is a launch-layer addition only. mcp_bundle floor ^0.4.3 → ^0.4.5 (internal-dependency freshness; no new symbol).

Fixed #

• Auth re-injection no longer fails (E4002) for sessions that use localStorage. applyProfileTo seeded localStorage / sessionStorage / indexedDb by running JS in the document, but the ops (page_view, page_audit_role, page_compare_actors, submit_form) applied setAuth before navigate — so the seeding ran against about:blank, where storage access throws a SecurityError, failing the whole injection (cookies-only sessions worked, masking it; surfaced when attach first reused a real Google session with 1 localStorage item). Injection is now split around navigation: cookies + extra headers (origin-independent) apply before navigate, storage seeding applies after the origin is loaded. applyProfileTo gains an AuthApplyPhase param (cookiesAndHeaders / storage / all), threaded through the setAuth action's optional phase param; all four actor+navigate ops now use the two-phase sequence. Backward-compatible (absent phase = all). Boundary: this fixes cookie-primary sessions (e.g. Google); a storage-primary SPA that reads localStorage before its first script may still need an init-script seed (follow-up). Tests: auth_profile_store_test.dart TC-413/414 (phase gating). Found via 0.1.3 attach dogfood (sbuilder).

Notes #

• Honest boundary: attach/persistent optimize session reuse, not "breaking a fresh SSO login inside automation" — a new Google login performed in an attached tab can still be flagged. The trusted path is an already-authenticated session.
• Tests: test/core/cdp_launcher_session_source_test.dart (attach ws:// owns-nothing + safe-close unit; real-Chrome integration: caller profile survives close · temp profile deleted) + auth_profile_store_test.dart TC-413/414 (phase-split injection). analyze 0 err/warn · 210 PASS.

Changed #

• BrowserRuntime.authStore widened from the concrete AuthProfileStore? to the BrowserAuthProfilePort? interface, so a host can inject its own backing store (e.g. an appplayer_secure-sealed profile store). Additive — AuthProfileStore implements BrowserAuthProfilePort, so existing callers are unaffected.
• mcp_bundle caret bumped ^0.4.0 -> ^0.4.3 (latest published; internal-dependency freshness).

Changed (cascade) #

• mcp_bundle caret bumped from ^0.3.0 to ^0.4.0. mcp_browser does not touch UiSection.pages directly, so this release is a caret-only cascade. Consumers should bump to ^0.1.1.

Added #

• Direct CDP browser engine and context lifecycle.
• Authenticated-session auth profile store and reuse.
• Structured operations — search, download, extraction templates.
• Pluggable audit subsystem (file / KV sinks, audit trail).
• Policy engine and policy ports.
• Engine / context / auth-profile registries.
• Browser-specific ports composing the 4-Primitive Contract from mcp_bundle.