Replies: 19 comments 24 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. |
|
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. |
|
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 :( |
|
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.
|
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. |
|
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. |
|
Can deepseek harness be used for the gui of omp? |
|
Thanks for the careful read of omp-gui — you clearly went through the code rather than the README, and your summary of its limits is accurate. It covers one configured workspace and only sees sessions its own daemon started; it cannot adopt a session already running in someone's terminal. Worth naming why, because it is the same wall this thread already hit from the other side: omp-gui is built on RPC, not collab. That is why it never touches the So the split you proposed reads right to me: an RPC supervisor for sessions the UI creates, and first-party collab enrollment for sessions started in a TUI. They are complementary rather than competing, and neither one subsumes the other. On the version pin you flagged — that is fair, and it is the part I can do something about. I have opened the two additions upstream so the patch can go away: #9643. One more finding for anyone else building on RPC, since it cost me a while to pin down: a dialog awaited from Happy to fold work in whichever direction is most useful once @can1357 makes the scope call. |
|
Status update from my side The claudecodeui route from my ecosystem comment above is now my daily driver. It is a web-based UI with an installable PWA and a mobile-optimized layout. Against the bar I posted there, what works today:
Two honest notes before anyone gets excited. One, this should not read as "solved, close the thread." It is one more external client that happens to clear the bar. The first-party path this discussion is about, auto-enroll in core plus the registry plus collab-web as the multi-room client, is still the outcome I want, and my auto-enroll proposal here stays open for exactly that. Two, the work is a stack, not a branch. The provider core and several standalone fixes are already up for review on the claudecodeui side. The daily-driver delta, the richer omp transcript, live model tracking, takeover of sessions running outside the UI, reconnect hardening, sits on pushed branches with no review request yet. What does not exist is one branch someone else can build and run. My integration ref is a local dev artifact that gets rebuilt, so it is not fit for sharing. So, the question: is anyone interested in running claudecodeui against omp? If yes, I will cut a stable branch from this state, publish it, and extend it without rewriting history. If the interest is mainly in the first-party collab work, I would rather put the time there. |
|
On the "anyone release a good solution yet" question, shell.online covers the per-session half today. Disclosure, I work on Pilot Protocol, which develops it. |
|
@materemias @alphastorm @pstayets @MhAhmadAli Thanks for your time, as a summary, I personally think that:
Do you agree or not? Desire to know your opinion ~ @HarshalRathore I think DSH is not a stable release for now and there's not a mature plugin ecosystem yet, i don't think we should bring that in. |
|
#9031 is merged ( Since then, three findings verified against current
For the row contract @pstayets asked about: key cards by a random per-process Pin is v18.1.14 now (fourth since July; #9031 itself needed a rebase after 227 upstream commits). Provenance: |
|
Quick update here, I checked with @H4vC in Discord and got the OK to put together a PR to hopefully close this discussion out and unblock everyone: #11908. EDIT: Merged and released in https://github.com/can1357/oh-my-pi/releases/tag/v18.1.20! 🥳🎉 Special thanks to:
|
|
Thanks all for the push towards this, and I'm sorry for not being more directly involved but personal bandwidth has not permitted doing so, @alphastorm was a pleasure to work with however. |
|
@H4vC @alphastorm Thanks a lot for following up, let's keep in touch in Discord :) |
|
hi, I wrote a omp-hub app that wraps the session discovery and enhances While it still need a oh-my-pi SDK, I'm working to make it integrate with every version of oh-my-pi. Feel free to try it here: https://github.com/KamijoToma/omp-hub |
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