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) --- .github/workflows/ci.yml | 60 ++++++ CHANGELOG.md | 22 ++ README.md | 20 +- package.json | 2 +- skills/pi-browser-harness/SKILL.md | 15 ++ src/cdp/discovery.ts | 96 ++++----- src/cdp/session.ts | 19 ++ src/cdp/target-factory.ts | 223 +++++++++++++++++++ src/client.ts | 138 ++++++++---- src/domains/isolated-tab.ts | 27 ++- src/domains/navigate.ts | 31 ++- src/domains/setup.ts | 6 +- src/index.ts | 16 ++ src/profile/bind.ts | 138 ++++++++++++ src/profile/browser-process.ts | 371 ++++++++++++++++++++++++++++++++ src/profile/command.ts | 168 +++++++++++++++ src/profile/launch.ts | 90 ++++++++ src/profile/list.ts | 171 +++++++++++++++ src/profile/paths.ts | 166 ++++++++++++++ src/profile/picker.ts | 73 +++++++ src/profile/store.ts | 105 +++++++++ src/setup.ts | 74 ++----- test/manual/profile-concurrency-test.ts | 192 +++++++++++++++++ test/manual/profile-e2e-test.ts | 295 +++++++++++++++++++++++++ test/profile/browser-process-test.ts | 108 ++++++++++ test/profile/list-test.ts | 156 ++++++++++++++ test/profile/paths-test.ts | 130 +++++++++++ test/profile/store-test.ts | 116 ++++++++++ 28 files changed, 2835 insertions(+), 193 deletions(-) create mode 100644 src/cdp/target-factory.ts create mode 100644 src/profile/bind.ts create mode 100644 src/profile/browser-process.ts create mode 100644 src/profile/command.ts create mode 100644 src/profile/launch.ts create mode 100644 src/profile/list.ts create mode 100644 src/profile/paths.ts create mode 100644 src/profile/picker.ts create mode 100644 src/profile/store.ts create mode 100644 test/manual/profile-concurrency-test.ts create mode 100644 test/manual/profile-e2e-test.ts create mode 100644 test/profile/browser-process-test.ts create mode 100644 test/profile/list-test.ts create mode 100644 test/profile/paths-test.ts create mode 100644 test/profile/store-test.ts diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 0d873cf..c93ad8d 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -34,3 +34,63 @@ jobs: - name: Verify npm package run: npm pack --dry-run > /dev/null + + # Profile discovery and pinning are the only parts of the harness whose + # behavior differs per operating system: user-data-dir locations, how the + # running browser is identified, and whether a --profile-directory launch is + # handed to the running browser by Chromium's ProcessSingleton. Chromium's + # source says all three behave the same everywhere; this job is what turns + # that into evidence on real macOS and Windows machines. + profiles: + name: Profiles (${{ matrix.os }}) + runs-on: ${{ matrix.os }} + strategy: + fail-fast: false + matrix: + os: [ubuntu-latest, macos-latest, windows-latest] + + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: 22 + cache: npm + + - name: Install dependencies + run: npm ci + + # Pure path/parsing/storage logic. Each run exercises its own platform's + # branch — the matrix is what gives all three coverage. + - name: Unit tests + run: | + npx tsx test/profile/paths-test.ts + npx tsx test/profile/list-test.ts + npx tsx test/profile/store-test.ts + npx tsx test/profile/browser-process-test.ts + shell: bash + + # The runner images ship Google Chrome on all three platforms. Linux has + # no display server, so the browser runs under Xvfb — the launch handshake + # needs a real (headful) browser, since headless Chrome does not honour + # --profile-directory window opening. + - name: Install Xvfb (Linux) + if: runner.os == 'Linux' + run: sudo apt-get update && sudo apt-get install -y xvfb + + - name: Profile end-to-end (Linux) + if: runner.os == 'Linux' + run: xvfb-run --auto-servernum npx tsx test/manual/profile-e2e-test.ts + + - name: Profile end-to-end (macOS / Windows) + if: runner.os != 'Linux' + run: npx tsx test/manual/profile-e2e-test.ts + shell: bash + + # Tab-creation concurrency is pure JS coordination — the same on every + # OS — so one platform is enough to guard the invariant. + - name: Tab concurrency (Linux only) + if: runner.os == 'Linux' + run: xvfb-run --auto-servernum npx tsx test/manual/profile-concurrency-test.ts diff --git a/CHANGELOG.md b/CHANGELOG.md index ed726e2..bbd641a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,28 @@ All notable changes to pi-browser-harness will be documented in this file. +## 0.10.0 — 2026-07-24 + +### Added + +- **`/browser-profile` — choose which browser profile the agent works in.** The command lists every profile in the connected browser, labelled `Name (email)` (or `Name (Profile 3)` when the profile has no signed-in account), marks the current selection, ordered the way the browser orders them. The choice is saved to `~/.pi/agent/browser-harness.json`, so it survives session termination, pi restarts, and applies across projects; a trailing `— Clear selection —` row restores the previous behavior. Picking a profile mid-session takes effect immediately — the harness closes its tabs and reopens its window in the chosen profile. +- **First-run profile prompt.** When no profile has been chosen, `/browser-setup` and the agent-callable `browser_setup` show the same picker before connecting, and report the result as `Browser profile: