Start a local Chrome when the target is an explicit local and none answers

Dedicated profile (~/.chrome-cdp-profile), macOS only, never for the
castle default. BU_LOCAL_CHROME_LAUNCH=off disables it.

1 files changed, 18 insertions, 0 deletions

diff --git a/FORK.md b/FORK.md
index ee041c9..c3a1815 100644
--- a/FORK.md
+++ b/FORK.md
@@ -135,6 +135,24 @@ tool runs, so a fresh session reports "not connected yet" rather than an error.
 from npm, so the patch cannot be silently reverted — which is exactly what the
 previous approach (patching `node_modules` in place) suffered from.
 
+## Launching a local Chrome
+
+With an explicit `local` target (`/browser-target local` or `BU_CDP_HTTP=local`) and no browser to
+attach to, discovery starts one (`src/cdp/local-launch.ts`) and waits for `127.0.0.1:9222` to answer.
+It never starts a browser for the castle default, and never when something already answers.
+
+It always uses a dedicated profile, `~/.chrome-cdp-profile`, never the user's own: Chrome ignores
+`--remote-debugging-port` on its default user-data-dir, and opening the signed-in profile unasked
+would be a surprise. macOS only; elsewhere discovery fails as before.
+
+| Variable | Effect |
+|---|---|
+| `BU_LOCAL_CHROME_LAUNCH=off` (also `0`, `no`, `false`, `none`) | never launch |
+| `BU_LOCAL_CHROME_PROFILE` | profile directory, default `~/.chrome-cdp-profile` |
+| `BU_LOCAL_CHROME_EXE` | Chrome binary, default the one in `/Applications` |
+
+There is no watchdog: if the launched Chrome dies, the next discovery starts another.
+
 ## Taking upstream releases
 
 The patch is a short series of fork commits on top of an upstream commit, so