Replies: 9 comments 8 replies
|
Count me in — this maps cleanly to what I've been thinking through against #6354. The way I'd frame it for a design call, it's two separable layers:
The linchpin is the process model, and it decides more than reconnect. Once sessions are hosted by a supervisor/daemon instead of being bound to a TUI, two things open up:
So the decisions I'd tee up for @can1357:
On privacy: a self-hosted relay reached over a tailnet (e.g. |
|
@materemias Hi~ do you have a discord or email or some other IM so we can DM each other to discuss this? |
|
sure, let's continue in email |
|
My version of this pipes omp collab protocol through a relay and tunnel as a cloudflare Access App. It works great and doesn't require anything more. I have a custom iOS app running against it. |
|
you still need to trigger /collab for each session you wanna be able to monitor/continue right? |
|
Anyone release a good solution for this yet? I'd love to use it if so. |
|
@rhlsthrm materemias and I have a plan that we want to bring two backbone features that 1. collab can be enabled by default 2. list all collab sessions. However we have to let our PRs get reviewed / merged :( |
|
Yes this is exactly what I'm envisioning as well, this would be a huge boost if it were built directly into the OMP first party setup. I would even pay for something like this. |
|
Following @materemias's two-layer framing — I went through the relevant code to see how much of the process-model question is already answered, and one detail changes the ordering of the work. The blocker is not survival. It is that
|
| Needed for remote control | Already in launch/protocol.ts |
|---|---|
| Persistent per-directory server | daemonBrokerEndpoint(projectDir, runtimeDir) — broker.sock, or \\.\pipe\omp-daemon-<wyhash> on Windows |
| Survive the launching client | DaemonSpec.persist, DaemonSpec.detached, OMP_DAEMON_IDLE_GRACE_MS |
| Spawn in a known folder | DaemonSpec.cwd, application, args, env |
| Attach / replay after reconnect | logs with cursor, follow, renderTerminalRows → terminalRows |
| Send input | send with data or SIGINT/SIGTERM/SIGHUP/SIGQUIT/SIGKILL |
| Lifecycle + capacity view | list, describe, wait, restart, stop; DaemonState, DaemonRestartPolicy |
| Authenticated local transport | DaemonWireRequest { id, token, … } over UDS / named pipe |
| Push on completion | daemon-completed notification to the owning socket |
It supervises PTYs at a fixed 120 × 40. So "borrow the shape from claude remote-control" may be closer to "point the existing broker at omp itself."
Worth noting @sorphwer's #6354 registry independently converged on the same conventions — per-process UDS/named pipe, newline-delimited JSON, per-request bearer auth, bounded buffers, owner-only 0700/0600 under ~/.omp/run/collab-hosts. Two registries with the same transport model is the thing to avoid before either lands.
Suggested ordering
This suggests a first step that is much smaller than the daemon decision and does not depend on it:
Step 0 — give /collab a handle. Decouple CollabHost from InteractiveModeContext down to what it actually needs (the session, the event stream, settings, and an output sink), and add the handle sibling. On its own this makes /collab work in RPC and ACP mode, which is useful immediately and independent of any UI work.
It also unblocks both open items without pre-committing the architecture: auto-enroll (#6171) becomes a call into a context-free host rather than something that needs a TUI, and #6354's registry gets a publisher that is not TUI-bound.
Step 1 — session survival. Whether that is the launch broker supervising omp --mode rpc, or RPC mode accepting a socket transport instead of stdio, is genuinely a maintainer call. But it is a narrower question once Step 0 is done, because at that point the only thing tying a session to a terminal is the stdio pipe.
Step 2 — the multi-room client. Agreed with @materemias that growing packages/collab-web beats a second app, since it keeps one E2E codebase and the room key never leaves the URL fragment.
Two constraints worth writing into the design now
Auto-enroll changes what a link means. Today a full link is 48 bytes — the 32-byte AES-256-GCM room key plus a 16-byte write token — and possession is the entire trust boundary. /collab is deliberate, so the user knows when a room exists. A global toggle creates rooms for sessions the user was not thinking about. Worth deciding up front whether collab.autoShare defaults to view-only (bare 32-byte key), and whether auto-created rooms publish to the relay before a client actually asks for them.
A multi-room client must not treat every agent_end as done. From docs/rpc.md: isTerminal: false means "maintenance or async delivery has scheduled more work." A phone reconnecting mid-turn will otherwise render finished sessions that are still running. Same document, same class of issue: responses must be correlated by id, not emission order.
On the privacy point
Agreed, and it is stronger than it sounds. The relay is content-blind by construction — per docs/collab.md it sees only room ids, connection counts, opaque ciphertext frames and their sizes, and a 4-byte routing prefix — and it is a small Go service exposing GET /, GET /r/<roomId>, POST /s, GET /s/<id>, GET /s/<id>/raw, GET /healthz. Self-hosting that behind a tailnet, as @materemias describes, means no public relay and no exposed ports. @nathanodle's Cloudflare Access setup is the same property reached a different way. That is a real differentiator against hosted-only alternatives, and it survives whatever process model gets chosen.
Happy to prototype Step 0 as a standalone PR if that ordering seems right — it is self-contained and does not commit anyone to a daemon design.
|
@Mustaqeem66 Thanks for your time and works! As for "Headless sessions already exist;It is that /collab cannot run outside the TUI." ----Why we need auto /collab headless sessions and access them from remote? In my practice, we just want to remotely access sessions that are opened by users from a mobile phone or another computer. I use headless omp sessions but they are already opened by my IM-bridge or some other scripts. Finally I wish related PRs can get merged first. |
|
Ecosystem check: remote access to omp is being built from outside Four efforts since we last synced here, one of them mine. Caveat up front: I have read the other three but not run them, so their capabilities below come from their docs. The bar I measure all of this against is the seamless version of this thread's title: continue any previous session, monitor and continue any active session, and start new ones, all from the phone.
The attach mechanisms split three ways. oh-my-portal tunnels the terminal itself, which is terminal-level access. claudecodeui mirrors and continues the live session through its own omp integration. session-gateway is the only one attaching through omp's own collab path, and to do that it ships a patch pinned to commit 89d6a8f from Jul 21 for auto-start and registration. omp-deck stays out of the attach race: it hosts its own SDK sessions, and by its docs that is not live attachment to arbitrary terminal sessions. The enrollment layer, #6354 plus #6171, is the piece session-gateway had to rebuild by hand. Landing those two makes the collab path supported instead of a fork, and gives omp one first-party attach story rather than none. |
|
One more data point since the comment above: pi-agent-dashboard, at 250 stars the largest dashboard in the pi ecosystem, states outright that Oh My Pi is not supported. The only omp path is a fork whose entire adaptation is one June commit, now 1065 commits behind upstream with no merge path. That is demand routed into a dead end. Its mechanism is also worth a look for #6171. A bridge extension registered globally loads into every session, auto-spawns a detached server, and mirrors the session, including TUI ones, over its own WebSocket protocol. Zero core changes. It works because the extension owns the protocol; it could not do this over /collab, since the room key and write token never leave the host process, which is the same reason auto-enroll has to live in core. Same caveat as my earlier comment: read, not run. |
|
Author of https://github.com/alphastorm/omp-session-gateway here - happy to contribute/upstream anything if it's potentially helpful, just let me know! |
|
Opening these PRs to help with discussion for: #6460 Following up on my offer above, and on @materemias's ecosystem check — thanks for the fair summary of omp-session-gateway. One correction to it, and then the first concrete piece. The pin moved. The gateway no longer ships against First PR#9031 — This one is a plain bug, independent of any of the architecture questions in this thread, so I sent it on its own.
The fix drops the precondition and bounds the map at 64 instead. Three new tests fail on unmodified source and pass with it. No wire-protocol change, nothing new visible to a read-only guest. What else is extractable, and what is notBeing honest about the split, because most of the gateway is not a good upstream PR as it stands:
On @Mustaqeem66's Step 0: giving Everything is reproducible from Update. Both now exist:
|
|
Follow-up on the offer above — I've now put our production experience into the two threads that own this rather than starting anything parallel:
An offer, and I want to be careful how it landsNeither enrollment thread has had a maintainer response since 22–23 July. That's not a complaint about @sorphwer or @materemias — #6354 is a finished 1,900-line PR sitting in review, and @sorphwer already said the blocker is "we have to let our PRs get reviewed / merged". We do have the whole thing working out-of-tree: auto-start with an But I'd rather not do that unasked, for two reasons. It would duplicate #6354's transport model, which @Mustaqeem66 specifically warned against. And it would put a newer PR in front of one that's been waiting a month, which isn't a precedent I want to set in someone else's repo. So: say the word and I'll open it, and I'll close it the moment #6354 lands. Otherwise the more useful thing is almost certainly a maintainer decision on #6171's four open questions — everything else, ours included, is downstream of that. |
|
@alphastorm Hi, thanks for you time and works. I acknowledge that to build an external daemon is the fastest way to ship this feature, considering that there's lots of PRs pending here. To make the context as short as possible (make it healthy to both human and AI) :
|
|
Thanks @sorphwer, I appreciate the feedback. I post both manually and programmatically and do review all output (including what you're referencing). In this thread specifically, I was trying to contribute things we'd learned from running the gateway in practice: the fork/patch maintenance cost, the pending-UI bug that became #9031, the registry failure mode we hit in production, and some implementation evidence around the open design questions. I also tried to keep the downstream gateway pieces separate and avoid stepping on your existing work. That said, I can definitely consolidate updates and keep future comments shorter where the same information can be communicated more concisely. If there are particular comments you would like me to take another look at, please point me to them - I'm happy to edit or remove anything that isn't adding useful context. I just don't want to remove technical details solely because AI was involved in helping me write or proofread them. |
Uh oh!
There was an error while loading. Please reload this page.
So the basic idea is to redo the same experience of Claude Code Remote , where:
I think the next step is to create website (update current collab chat room)or app that looks like the 'Remote' in Claude mobile app's Code tab.
Therefore I sincerely invite @can1357 to make the final design decision and invite @materemias to work with me to implement this feature. We have already made some works for this.
More context: I believe that the only missing block for me is this 'remote control' feature, compared with Claude Code. And this is almost the only reason why I still need to use Claude Code or Codex. I think that another big advantage of omp is that user can build their own relay and make their transcript safe, which makes omp very competitive.
All reactions