From 6dd79f7c3bafacba54acb2840f8655fcb05318bf Mon Sep 17 00:00:00 2001 From: Aman Kumar <145339995+amankumarsingh77@users.noreply.github.com> Date: Sat, 25 Jul 2026 00:23:05 +0530 Subject: feat: pin the agent to a chosen browser profile (#16) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * 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) --- src/profile/store.ts | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 src/profile/store.ts (limited to 'src/profile/store.ts') diff --git a/src/profile/store.ts b/src/profile/store.ts new file mode 100644 index 0000000..c8b8952 --- /dev/null +++ b/src/profile/store.ts @@ -0,0 +1,105 @@ +/** + * Durable persistence for the selected browser profile. + * + * The pin must outlive session termination, so it cannot live in pi's session + * entries (`pi.appendEntry`, see src/state.ts) — those die with the session. + * It is a small JSON file in pi's agent config dir instead, shared by every + * project on the machine. + * + * The pin deliberately stores only `{ userDataDir, profileDir }`. A + * `browserContextId` is NOT persisted: Chrome mints fresh context ids on every + * browser run, so a stored one would be a stale pointer at best and a pointer + * into the wrong profile at worst. The context is re-resolved on each connect. + * + * Every read failure degrades to "no pin" rather than throwing — a corrupt + * file must never break browser control. + */ + +import { mkdir, readFile, rename, unlink, writeFile } from "node:fs/promises"; +import { randomUUID } from "node:crypto"; +import { dirname } from "node:path"; +import { type Result, err, ok } from "../util/result"; +import { pinFilePath } from "./paths"; + +export type ProfilePin = { + /** User-data-dir the profile belongs to — guards against browser switches. */ + readonly userDataDir: string; + /** Profile subdirectory, e.g. "Profile 1". */ + readonly profileDir: string; + /** Label captured at selection time, for display without a disk re-read. */ + readonly label: string; + /** ISO timestamp of the selection. */ + readonly savedAt: string; +}; + +type PinFile = { + readonly version: 1; + readonly profile: ProfilePin | null; +}; + +const CURRENT_VERSION = 1; + +const parsePin = (value: unknown): ProfilePin | null => { + if (typeof value !== "object" || value === null || Array.isArray(value)) return null; + const o = value as Record; + const userDataDir = o["userDataDir"]; + const profileDir = o["profileDir"]; + const label = o["label"]; + const savedAt = o["savedAt"]; + if (typeof userDataDir !== "string" || userDataDir.length === 0) return null; + if (typeof profileDir !== "string" || profileDir.length === 0) return null; + return { + userDataDir, + profileDir, + label: typeof label === "string" && label.length > 0 ? label : profileDir, + savedAt: typeof savedAt === "string" ? savedAt : "", + }; +}; + +/** + * The persisted pin, or null when nothing is pinned, the file is missing, or + * it cannot be parsed. A file written by a newer version is treated as "no + * pin" rather than guessed at. + */ +export const readPin = async (): Promise => { + let raw: string; + try { + raw = await readFile(pinFilePath(), "utf8"); + } catch { + return null; + } + try { + const parsed: unknown = JSON.parse(raw); + if (typeof parsed !== "object" || parsed === null) return null; + const file = parsed as Record; + if (file["version"] !== CURRENT_VERSION) return null; + return parsePin(file["profile"]); + } catch { + return null; + } +}; + +/** + * Replace the pin atomically: a sibling temp file plus rename, so a crash + * mid-write can never leave a half-written pin behind. + */ +const writePinFile = async (profile: ProfilePin | null): Promise> => { + const target = pinFilePath(); + const tmp = `${target}.${randomUUID()}.tmp`; + const payload: PinFile = { version: CURRENT_VERSION, profile }; + try { + await mkdir(dirname(target), { recursive: true }); + await writeFile(tmp, `${JSON.stringify(payload, null, 2)}\n`, "utf8"); + await rename(tmp, target); + return ok(undefined); + } catch (e) { + await unlink(tmp).catch(() => {}); + return err(`could not save profile selection to ${target}: ${e instanceof Error ? e.message : String(e)}`); + } +}; + +/** Persist the selected profile. */ +export const writePin = (pin: ProfilePin): Promise> => writePinFile(pin); + +/** Clear the selection, restoring the harness's unpinned behavior. */ +export const clearPin = (): Promise> => writePinFile(null); -- cgit v1.2.3