sz-chrome-remote-cdp.git/src/profile/bind.ts, branch master

fix(profile): never prompt for a profile when driving a remote browser

2026-10-14T11:19:26+00:00

Profile selection works by launching the browser with --profile-directory and letting ProcessSingleton delegate to the running process, which only reaches a browser on this machine. discoverEndpoint() already withholds userDataDir for a remote target, but resolveUserDataDir() fell through to the local candidate dirs, so the picker offered this disk's Chromium profiles for a browser on another host - on castle, Brave's profiles for a Chrome on :9223. Pinning one launched a local browser and polled the remote for a sentinel that could never appear, failing after the seed deadline; seedProfileWindow()'s mismatch guard missed it because connectedDir is undefined on the remote path. Setup now returns early instead of prompting - the question had no actionable answer, and since cancelling stores nothing it returned every session. /browser-profile and seedProfileWindow() refuse with the reason, the latter catching a pin left over from a local session.

refactor: attach and windowId become session methods

2026-08-02T13:42:46+00:00

cdp/attach.ts and cdp/window.ts were a module each for a single `map(await session.callBrowser(...))` one-liner that took the session as its first argument — two files, two imports and two names for what the session can expose itself. They are now session.attach(targetId) and session.windowId(targetId). session.ts also repeated `targetId ? tabs.get(targetId) : undefined` eight times; that is now currentTab(). Co-Authored-By: Claude Opus 5 (1M context)

refactor: tidy the whitespace the comment removal left behind

2026-08-02T13:42:46+00:00

Drops leading blank lines where a file header was removed, collapses double blank lines, and closes the empty catch/handler blocks whose only content had been a comment. Whitespace only. Co-Authored-By: Claude Opus 5 (1M context)

refactor(profile): strip comment noise

2026-08-02T13:42:46+00:00

Removes module banners and comments restating the code. Keeps one-line notes for the ProcessSingleton user-data-dir rule, the sentinel-URL and async-spawn-error quirks, the replicated getAgentDir, pi's tilde-expansion mirroring, the Windows wmic removal, the macOS/Linux process-identification quirks, the picker's undefined-means-cancel contract, and the deliberately unpersisted browserContextId. Co-Authored-By: Claude Opus 5 (1M context)

refactor(profile): drop CDP casts in favour of the typed boundary

2026-08-02T13:42:46+00:00

Co-Authored-By: Claude Opus 5 (1M context)

refactor(cdp): extract attachTo, getWindowId, evaluateJson helpers

2026-08-02T13:42:46+00:00

Target.attachToTarget was decoded at 5 sites, Browser.getWindowForTarget at 5, and Runtime.evaluate unwrapped at another. Each is now one typed helper. Deletes the dead cdp/window-binding.ts. Co-Authored-By: Claude Opus 5 (1M context)

fix: kill leaked Chrome processes on profile seed failure

2026-07-25T19:03:44+00:00

When a profile is pinned and ProcessSingleton fails to delegate, the spawned Chrome process starts a full second browser instance. The sentinel never appeared, but the spawned process was never killed (detached + unref'd + reference discarded), accumulating zombie browsers that consume RAM. Three changes: - Store child process ref and expose kill() on ProfileWindowHandle. Call kill() when the sentinel doesn't appear within the timeout. - Only clear profileContextId when the browser UUID changes (Chrome mints a fresh UUID on every launch), avoiding unnecessary re-spawns. - Don't clear profileContextId in setProfilePin when the pin hasn't changed, preventing gratuitous re-spawns on session_start.

feat: pin the agent to a chosen browser profile (#16)

2026-07-24T18:53:05+00:00

* feat: pin the agent to a chosen browser profile (#15) Harness tabs were created with a bare Target.createTarget, which places them in Chrome's defaultBrowserContextId — and that value follows window focus. Which profile the agent acted as therefore depended on which browser window the user last clicked, so the same task could run as a work account on one run and a personal account on the next. /browser-profile lists the connected browser's profiles as "Name (email)" and pins one to ~/.pi/agent/browser-harness.json, so the choice outlives the session. The same picker appears on first browser_setup when nothing is pinned; with no interactive UI, or on cancel, setup continues with a note and the previous behavior. Chrome offers no direct route to another profile: Target.createTarget rejects a foreign browserContextId, and openerId does not inherit the opener's context. The window is opened through the browser's own command line (--profile-directory, handed to the running browser by Chromium's ProcessSingleton) and identified by a unique file:// sentinel page, since a bare about:blank#token argument is discarded. Further tabs come from window.open evaluated with userGesture: true — the only CDP-reachable way to place a tab in a non-default browser context — correlated by a unique token so concurrent isolated tabs stay distinct. A failed handshake is reported, never silently redirected to another profile. All four tab-creation sites now funnel through cdp/target-factory, so open_urls and the isolated tabs behind web_search / read_page cannot run with a different profile's cookies than the visible tabs. Also fixed along the way: snap Chromium is discovered, Windows uses %LOCALAPPDATA%, browsers launched with an explicit --user-data-dir are found, the running browser is chosen by ranking candidates against the connected user-data-dir rather than taking the first process found, and an installed-but-closed browser no longer reads as running. CI runs the profile suites and a real-browser end-to-end test on ubuntu, macOS, and Windows — profile discovery is the one part of the harness whose behavior genuinely differs per OS. Co-Authored-By: Claude Opus 4.8 (1M context) * fix: single-flight harness window creation Isolated tabs run concurrently (browser_read_page is registered unserialized), so several could each find "no harness window" and create one — two blank windows before this feature, two LAUNCHED profile windows after it. ensureHarnessWindow now shares one in-flight creation per client. Sharing introduces a second hazard: freshlyCreated is a claim on the seed tab, and if every waiter received it, they would all drive the same tab. Only the caller that started the creation keeps the claim; the rest open their own tab beside it. Covered by test/manual/profile-concurrency-test.ts (five concurrent isolated tabs, pinned and unpinned: distinct targets, one window, correct profile), wired into CI on Linux only — the coordination is pure JS and identical across platforms. Co-Authored-By: Claude Opus 4.8 (1M context) * fix: tilde expansion differs by purpose on Windows CI on windows-latest caught this: join("~", "x") yields "~\x" there, and expandTilde only handled "~/". The two uses are not the same, so they no longer share a helper. The agent dir stays byte-compatible with pi's own expandTildePath ("~/" only, every platform) — being more lenient would put the pin file somewhere pi never looks. $CHROME_USER_DATA_DIR is ours to interpret, so it accepts "~\" as well, which is what a Windows user would type. Co-Authored-By: Claude Opus 4.8 (1M context) --------- Co-authored-by: Claude Opus 4.8 (1M context)