omp-session-gateway — every running OMP session on your phone, no /collab

[alphastorm]

Status first, because it matters: this is an implemented pre-alpha, not a release. No operating system, browser, or Android device is advertised as supported, there is no alpha artifact, and it requires a patched OMP. It is posted here because @materemias's ecosystem check in #6460 raised it and @rhlsthrm asked whether anything usable exists yet — this is what it does and, just as usefully, what it does not.

Repository: https://github.com/alphastorm/omp-session-gateway

What it is

A loopback daemon plus an installable PWA that lists every currently running interactive OMP process on one machine and opens OMP's existing collab-web against the one you pick, for View or Control, over Tailscale Serve. No /collab, no copying links.

The deliberate design constraint is that it is a session directory and capability broker, not a second agent UI. It renders no transcript of its own — it launches the upstream client. That keeps one E2E codebase, which is the same instinct @materemias described for growing collab-web into a multi-room client rather than building a separate app.

How it differs from the neighbours

Against the four projects listed in #6460: oh-my-portal tunnels the terminal, claudecodeui mirrors through its own integration, omp-deck hosts its own SDK sessions. This one attaches through OMP's own collab path, which is why it needs a patch — and why landing #6354 and #6171 would make most of that patch unnecessary.

Security posture

The parts worth reviewing rather than trusting:

• The HTTP listener binds 127.0.0.1 only. The supported remote path is Tailscale Serve over tailnet HTTPS; Funnel is never a documented deployment path.
• The session list and its SSE stream are metadata only. A view or control capability is fetched just-in-time, after an explicit tap, bound to the session's generation — a stale card gets 409, not a newer capability.
• Capabilities never touch disk, query strings, cookies, Local/Session Storage, IndexedDB, Cache Storage, or logs. A leak suite scans for synthetic canaries in all of those and fails the build.
• The registry is in-memory only. A daemon restart starts empty and is repopulated only by live OMP processes.
• OMP publishes over a Unix socket (current-user named pipe on Windows) behind a nonce-bound mutual HMAC handshake; the publisher key never crosses IPC.
• Generation N is revoked before N+1 is published on switch, branch, resume, or relay replacement, so a stale control capability is not reachable.

What is not qualified

Everything that needs real hardware. Physical Android, distinct allowed/denied tailnet devices, reboot and login persistence, upgrade and rollback, and signed-candidate artifacts are all unqualified against the current pin. The release ledger tracks each row and the alpha decision is NO-GO. Treat published archives as engineering inputs.

It also pins one exact OMP commit — currently v17.3.8 — and ships an apply-ready mbox. That pin is the honest cost of attaching through the collab path from outside: today's refresh from v17.0.6 needed a regenerated patch because four files had moved underneath it.

Contributing back

First piece is up: #9031 retains a host UI request raised before any writer joins. CollabHost already replays pending requests to a joining writer, but the entry was never created without one, so the ask was discarded. That is a plain bug and stands on its own.

The controller and registry publisher — the part @materemias identified as rebuilt by hand — is not a PR yet, because it is a new subsystem spanning several packages and overlaps #6354/#6171. That belongs in a design conversation before code, not in a surprise diff.

Happy to split, reshape, or drop any of it if it duplicates work already in flight.