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

* 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) <noreply@anthropic.com>

* 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) <noreply@anthropic.com>

* 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) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

1 files changed, 60 insertions, 0 deletions

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