test(hub): the Firefox probe stops opening the developer's own profile

`test_sticky_header.py[firefox]` failed with twelve setup errors whenever
a Firefox was open, and the note in CLAUDE.md said to close it and trust
the Chrome half meanwhile. The cause was not snap's single instance: the
harness pointed HOME at a throwaway directory, snapd sets its own HOME
inside the sandbox, and that directory came back empty on every run — so
Firefox opened the real profile, which the open browser locks.

`--profile` needs a path the sandbox can see: the snap has a private
/tmp, and its home interface grants no hidden directory. Both refusals
print "Firefox is already running", which it also prints when nothing is.

24 passed in 15s with a Firefox open throughout, against 12 errors in 60s.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 20 insertions, 12 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index a7ecbca..f0f90d5 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -163,18 +163,26 @@ These are about working on the tree rather than about the design:
 - **The SPA served in production may be older than this tree.** Check the served
   `/a/<hash>/` against `meshbay_hub.api.webapp.ASSET_V` before concluding a fix
   is missing. `site/` and the Caddy config have never been deployed
-- **`test_sticky_header.py[firefox]` needs no Firefox instance on the machine,
-  and says nothing about the code when one is there.** The harness launches
-  `firefox --headless --screenshot` with `HOME` pointed at a throwaway
-  directory, which isolates the *profile* and not snap's single instance: with
-  any Firefox already up it prints "Firefox is already running, but is not
-  responding", never loads the page, and the fixture times out at 60 s — eleven
-  errors at setup that look like a regression and are not. Neither
-  `--no-remote` nor `--new-instance` changes it; a failed run also appears to
-  leave a process behind, which blocks the next one. Before reading anything
-  into these: `ps -eo pid,etimes,args | grep firefox`, and re-run against a
-  stashed tree. The `[chrome]` half of the same file covers the same geometry
-  and is the one to trust meanwhile
+- **A sandbox can refuse a path without saying so, and the browser blames
+  something else.** `test_sticky_header.py[firefox]` failed with twelve setup
+  errors whenever the developer's own Firefox was open, and the note that used
+  to be here said to close it and trust the `[chrome]` half meanwhile. The
+  cause was not snap's single instance. The harness pointed `HOME` at a
+  throwaway directory to isolate the profile; snapd sets its own `HOME` inside
+  the sandbox, so that directory came back **empty on every run** — the tell,
+  and it was there all along — and Firefox opened the developer's real profile,
+  which their browser had locked. `--profile` did not help either, for two more
+  sandbox rules: the snap has a private `/tmp`, so a directory made there is
+  not the one it sees ("Could not find profile folder"), and its `home`
+  interface grants no *hidden* directory, so `~/.cache` is refused too. Both
+  refusals surface as **"Firefox is already running, but is not responding" —
+  which it also prints when nothing is running at all**, so the message names
+  neither the real cause nor even the right question. A plain directory under
+  `$HOME` (the probe prefers `~/snap/firefox/common`) fixes it: 24 passed in
+  15 s with a Firefox open throughout, against 12 errors in 60 s before. The
+  rule worth keeping: **when a sandboxed program cannot see a path, find out
+  what it can see before believing what it says** — and an isolation directory
+  that stays empty is not isolating anything
 - **One UI source.** `packages/meshbay-hub/src/meshbay_hub/static/` is the
   interface, for the web and the app alike; `packages/meshbay-client/scripts/
   sync-ui.js` copies it (`npm run sync-ui`) and CI fails if the copy drifts —