diff options
| -rw-r--r-- | FORK.md | 44 |
1 files changed, 34 insertions, 10 deletions
@@ -20,12 +20,18 @@ Upstream can only reach a browser on localhost: `createDaemonTransport`) - the daemon resolves Chrome with `discoverWsUrl()` (`src/daemon/bridge.ts`) - that probe is hardcoded to `127.0.0.1` (`src/cdp/discovery.ts`) -- `BU_CDP_WS`, the documented remote escape hatch, is read only by the - in-process client (`src/client.ts`) — which that path never touches, so it has - no effect on the extension +- `BU_CDP_WS`, upstream's remote escape hatch, pins a full WebSocket URL -Without the patch the only option is relaying the remote browser onto localhost -(ssh tunnel or socat), which means a local service on every client machine. +Before upstream 0.11.0, `BU_CDP_WS` was read only by the in-process client and +so did nothing for the extension. 0.11.0 (`6d30009`) moved it into +`discoverEndpoint()`, so the daemon now honours it too. It still does not cover +this fork's use: the URL embeds the browser UUID, which Chrome re-mints on every +launch, and it is read once when the daemon starts. There is also no default, +no fallback and no way to switch from inside pi. + +Without the patch the options are pinning `BU_CDP_WS` and re-setting it after +every remote restart, or relaying the remote browser onto localhost (ssh tunnel +or socat), which means a local service on every client machine. `BU_CDP_HTTP="host:port"` is resolved inside `discoverEndpoint()`, so daemon and client both honour it. It names an **HTTP** endpoint, not a WebSocket URL, @@ -78,6 +84,11 @@ Precedence is `BU_CDP_HTTP` > `/browser-target` > built-in default, so a one-off `BU_CDP_HTTP=… pi` is never silently overridden by a choice made days ago. When the variable is set, `/browser-target` says so instead of pretending to obey. +Upstream's `BU_CDP_WS` sits above all of these: `discoverEndpoint()` returns it +before consulting the fork's target, so an explicit WebSocket URL still wins. +`/browser-status`, `/browser-target` and the system prompt do not know about it, +and describe the `BU_CDP_HTTP`/stored/default target even when it is set. + The asymmetry is deliberate. An explicit endpoint is an instruction, so failing to reach it must not quietly automate a different browser — that would drive your own signed-in Chrome instead of the shared one. The default is only a @@ -93,8 +104,8 @@ previous approach (patching `node_modules` in place) suffered from. ## Taking upstream releases -The patch is a single commit on top of an upstream tag, so rebasing keeps it -that way: +The patch is a short series of fork commits on top of an upstream commit, so +rebasing keeps it that way: ``` git fetch upstream @@ -102,9 +113,22 @@ git rebase upstream/main # or: upstream/main --onto a specific tag git push --force-with-lease origin master ``` -Conflicts to expect are confined to `src/cdp/discovery.ts` (the -`discoverEndpoint()` short-circuit and the `host` parameter on -`queryLiveWsUrl`) and `src/setup.ts` (the skipped local-process precondition). +Conflicts to expect are mostly in `src/cdp/discovery.ts` (the +`discoverEndpoint()` short-circuit, placed after upstream's `BU_CDP_WS` check, +and the `host` parameter on `queryLiveWsUrl`) and `src/setup.ts` (the skipped +local-process precondition). Upstream refactors also touch the fork's hunks in +`src/index.ts` (imports, `/browser-status`, `before_agent_start`), +`src/prompt.ts`, `src/daemon/spawn.ts` (`stopDaemon`), `src/profile/*` and +`CHANGELOG.md`. + +Verify with `npm run check` (typecheck, the boundary scanner and the tests). +The boundary scanner rejects unguarded casts, so parse JSON with +`src/util/guards.ts`. `test/daemon/entry-imports-test.ts` walks the daemon's +import graph, which includes `endpoint.ts` and `target-store.ts`, and fails if +it reaches a non-runtime dependency such as `typebox`. The fork's own tests +(`test/cdp/endpoint-test.ts`, `test/cdp/target-store-test.ts`) use a +hand-rolled `check()` rather than `node:test`; the test glob still runs them and +a failure exits non-zero. The setup precondition skips `isBrowserRunning()` whenever the resolved target is remote — by env var, `/browser-target` choice, or the built-in default — not |