Seamlessly connect all oh-my-pi collab session from anywhere

[sorphwer]

So the basic idea is to redo the same experience of Claude Code Remote , where:

1. Remote control (i.e. /collab enabled) can be enabled automatically when any chat session is started (@materemias 's feat(collab-web): global remote toggle — auto-enroll all sessions into an authenticated web UI with a session side panel #6171 is for this)
2. We will have a mobile app or website that sync all sessions that enabled collab, where user can view a list and select one to continue their work. (my feat(collab): list active local host sessions #6354 has added a 'list' feature for this)

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.

[materemias]

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:

1. Enrollment — getting sessions into a discoverable registry. feat(collab): list active local host sessions #6354 is the discovery backbone. The one piece that has to live in core is auto-enroll: the room key + write token never leave the host process and aren't exposed to any hook/extension, so nothing outside omp itself can start collab or capture a joinable link. So this is a core toggle (e.g. collab.autoShare) that starts collab per session and publishes to the registry — not something a plugin can do.

2. Presentation — the Remote-like UI. My lean is to grow collab-web into a multi-room client (one client holding N rooms, a sidebar/switcher fed by the registry) rather than a separate app, so the E2E client stays one codebase.

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:

• attach/reconnect to any running session after the terminal is gone, and
• spawn new sessions remotely in a known folder — optionally worktree-isolated — which is the other half of the "control from my phone" experience.

claude remote-control is a good reference for that surface: a persistent per-dir server, one session pre-created so there's somewhere to type, --spawn same-dir|worktree|session, --capacity, --permission-mode, and resume via --session-id / --continue. Worth borrowing the shape.

So the decisions I'd tee up for @can1357:

• The daemon/supervisor model itself (survival + attach + remote spawn) — everything hangs off this.
• Where the multi-room view lives: extend collab-web, or a new surface.

On privacy: a self-hosted relay reached over a tailnet (e.g. tailscale serve) keeps the entire remote-control path private — no public relay, no exposed ports, secrets never leaving your own infrastructure. That relay + tailnet combo is exactly the edge you called out, and a real differentiator vs. hosted-only alternatives.

[sorphwer]

@materemias Hi~ do you have a discord or email or some other IM so we can DM each other to discuss this?

[materemias]

sure, let's continue in email

[nathanodle]

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.

[materemias]

you still need to trigger /collab for each session you wanna be able to monitor/continue right?

[rhlsthrm]

Anyone release a good solution for this yet? I'd love to use it if so.

[sorphwer]

@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.
After that we want to enhance or redo the current collab room, the overall experience should be very similar with Claude Code Mobile App - Code - Remote Control.

However we have to let our PRs get reviewed / merged :(

[rhlsthrm]

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.

[Mustaqeem66]

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 /collab cannot run outside the TUI.

In packages/coding-agent/src/slash-commands/builtin-collaboration.ts, /collab, /join and /leave are registered with only a handleTui handler. Every neighbouring command in the same file — /advisor, /export, /dump, /share, /browser — supplies a handle as well.

slash-commands/types.ts makes the consequence explicit. handle is the "Text/ACP-mode handler … invoked from the ACP dispatcher and, via the TUI adapter, when no handleTui override is provided," and it "MUST NOT depend on TUI-only state." handleTui is for "anything else that requires InteractiveModeContext."

And CollabHost holds one directly:

export class CollabHost {
	#ctx: InteractiveModeContext;

So auto-enroll as specified in #6171 — "every new session auto-registers" — cannot be built on the existing host for any session that is not an interactive TUI. That includes every headless session, which matters because of the next point.

Headless sessions already exist; they just cannot survive a detach

omp --mode rpc (docs/rpc.md) is already a complete agent session with no TUI: prompt / steer / follow_up / abort, switch_session, branch, compact, handoff, and the full agent_start → message_update → tool_execution_* → agent_end event stream over newline-delimited JSON.

The gap is one sentence in the same document:

When stdin closes, pending extension UI, host-tool, and host-URI requests are rejected; accepted commands are drained, the session is disposed, and the process exits with code 0.

A session's lifetime is bound to one stdio pipe. That is the actual "terminal is gone" problem — not the TUI as such.

The supervisor you are describing is already in the repo

packages/coding-agent/src/launch/ is a cross-process daemon broker, and its shape matches the claude remote-control surface almost line for line:

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.

[sorphwer]

@Mustaqeem66 Thanks for your time and works!
Agreed, I think we should avoid implementing two registries, which is not elegant.

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.

[materemias]

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.

• omp-session-gateway: loopback daemon plus mobile PWA that discovers every live interactive omp process and opens collab-web for view or control behind Tailscale Serve. Closest to what we sketched in this thread.
• omp-deck: web cockpit embedding the omp SDK in-process. Multi-session chat, plan-mode approval, routines, Telegram bridge.
• oh-my-portal: skills plugin exposing a web chat and the real terminal through tmux and ttyd over Portal tunnels. Multi-agent.
• claudecodeui: my open siteboon/claudecodeui#1143 adds omp as a first-class provider over ACP stdio. The UI lists projects, starts new sessions, lists and continues existing ones, and mirrors a session still running in the terminal. Zero omp changes, no patch.

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.

[materemias]

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.

[materemias]

Another implementation appeared today: omp-gui. This one is unusually close to the daemon half we discussed. A Bun daemon owns one omp --mode rpc child per session, supports concurrent sessions, reconnect replay and final transcript resync, and wraps vendored collab-web renderers instead of writing another transcript. It can list and resume persisted sessions and start new ones.

Against the bar above, it currently covers one configured workspace and only monitors sessions owned by its daemon. It does not attach to arbitrary sessions still running in terminal TUIs, so it is not a complete remote-control replacement.

It also found two precise upstream gaps. The project applies a local patchedDependencies patch to @oh-my-pi/pi-coding-agent@18.0.1 because RpcClient drops extension UI requests and command output frames. Those are needed for approval dialogs and slash command output. This does not patch the user's global omp, but it pins the GUI to one SDK version until the two additions land upstream.

My read is that this validates the supervisor model for sessions created by a remote UI. It does not remove the enrollment problem for sessions started elsewhere. The clean split still looks like an RPC daemon for remotely created sessions, plus first-party collab enrollment through #6354 and #6171 for TUI sessions. Same caveat as above: docs and code read, not run.

[alphastorm]

Author of https://github.com/alphastorm/omp-session-gateway here - happy to contribute/upstream anything if it's potentially helpful, just let me know!

[alphastorm]

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 89d6a8f from Jul 21. It now pins v17.3.8 (858f7dd91fff9b84cf8a2c6a6bb85aa0e6d03a55) as of today. The old patch genuinely did not survive: interactive-mode.ts, agent-session.ts, session-manager.ts, and builtin-registry.ts all conflicted, which is a fair illustration of @materemias's point that carrying this outside core is a fork tax rather than a one-time patch.

First PR

#9031 — fix(collab): retain host UI requests until a writer joins

This one is a plain bug, independent of any of the architecture questions in this thread, so I sent it on its own.

CollabHost already replays pending UI requests to a peer that joins with write access — #handlePeerJoin iterates #pendingUi and sends each one. That path could never fire, because requestGuestUi returned null whenever #hasWritablePeers() was false, so a request made before a writer joined was dropped and no entry ever existed to replay. A host that asks a question while nobody is connected silently discards it.

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 not

Being honest about the split, because most of the gateway is not a good upstream PR as it stands:

• Ready-ish, needs a design decision first. The auto-start controller and the local registry publisher. This is the piece @materemias correctly identified as "the piece session-gateway had to rebuild by hand", and it overlaps directly with feat(collab): list active local host sessions #6354 and feat(collab-web): global remote toggle — auto-enroll all sessions into an authenticated web UI with a session side panel #6171. It is a new subsystem spanning several packages, which CONTRIBUTING.md says belongs in Discord before implementation — and the implementation already exists downstream, so I'd be opening that conversation late and saying so. I'm not going to drop a large PR on you without that. Happy to start it if there's appetite.
• Deliberately not upstreamed. The daemon, the PWA, Tailscale Serve identity handling, and the capability broker. Those are gateway concerns, not omp concerns.
• One thing worth flagging even if nothing else lands. The gateway's client needs the host to answer an optional encrypted gateway-health-ping with a gateway-health-pong. There is no such seam in v17.3.8, so we carry it downstream. It fails inert rather than loudly — the client only enables probing after a seed pong — which took a while to notice. If a first-party attach story ever wants end-to-end relay liveness as opposed to passive-traffic liveness, that seam is the missing bit.

On @Mustaqeem66's Step 0: giving /collab a handle alongside handleTui matches what we hit in practice. Our controller only works because it is driven from InteractiveModeContext; a context-free host is what would let enrollment stop being TUI-shaped, and it would have removed a good chunk of what we had to patch.

Everything is reproducible from patches/oh-my-pi — the mbox applies to pristine v17.3.8 and records the exact tree it produces. Happy to split any of it differently, or to drop pieces entirely if they duplicate #6354/#6171.

---

Update. Both now exist:

• fix(collab): retain host UI requests until a writer joins #9031 — the retention fix described above, open for review.
• omp-session-gateway — every running OMP session on your phone, no /collab #9036 — a Show and tell writeup of the gateway itself, with the full security posture and an explicit list of what is not qualified, so it is not mistaken for a release.

[alphastorm]

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:

• feat(collab): list active local host sessions #6354 (@sorphwer's registry) — a full review. One item I think is a merge blocker: querySnapshot maps any socket error to dead, and listEntry then prunes, deleting the socket file. For EMFILE/EACCES/EAGAIN that's a false verdict, and since publication happens once at connect with no republish path, unlinking a live host's socket leaves it listening on an unlinked inode — undiscoverable for the rest of its lifetime. We hit that exact inode failure from the other direction in production and lost a week to it, because every component still reports itself healthy. Cheap fix: discriminate on err.code.
• feat(collab-web): global remote toggle — auto-enroll all sessions into an authenticated web UI with a session side panel #6171 (@materemias's auto-enroll) — evidence against the four open decisions @roboomp listed, in particular that listing and interacting don't need to share an authorization boundary (metadata-only list, capability fetched just-in-time and generation-bound), and that the daemon/supervisor question doesn't gate auto-enroll + panel if you drop resume-after-exit. Also one correctness requirement nobody has named: revoke generation N before publishing N+1, or a stale card can still reach control for a session that changed underneath it.
• fix(collab): retain host UI requests until a writer joins #9031 — the one piece that was genuinely independent is already up: CollabHost discards a UI request raised before any writer joins, even though the replay path for a later writer already exists.

An offer, and I want to be careful how it lands

Neither 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 off | view | control switch, generation-safe publication with revoke-before-replace, mutual-HMAC authenticated local IPC, and a phone client driving it daily. If it is genuinely faster for @can1357 to review one implementation than to converge three, I'm happy to open it as a PR.

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.

[sorphwer]

@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) :

1. You don't need to introduce yourself 3 times in both PRs and the Discussion. I hope we can all discuss this feature in the Discussion, and PR comments should be used to review codes.
2. Kindly review your Agent's output when you decide to send it in Github comments. Your comments contain noise and it takes time to understand.

[alphastorm]

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.

[HarshalRathore]

Can deepseek harness be used for the gui of omp?

[LaneSun]

Great idea, I will give it a try!

[rhlsthrm]

Please let us know if you make this work.

[LaneSun]

Based on my experience advancing this with Agent over the past few days, the following path is not viable:

• Implementing a DSH plugin that directly launches an OMP Profile: DSH's plugin system is tightly coupled with its core runtime (essentially the Harness itself), so it is impossible to replace the Agent with OMP while retaining the plugin system.

The following paths are not very practical:

• Having DSH use OMP as a SubAgent through its exposed RPC/ACP: using it merely as a SubAgent is not very meaningful.
• Developing a standalone CLI application to launch OMP and connecting the DSH Web GUI to its RPC/ACP: OMP's externally exposed functionality through interfaces is quite limited.

Therefore, if pursuing a DSH-based GUI that can fully replace the TUI, the best approach is to fork OMP, add a package for GUI mode, and modify a limited amount of code to enable the CLI to support launching this mode.

The result is this repository: https://github.com/LaneSun/omp-web

It basically implements most of the TUI features (including Settings, Rollback, Commands, Workspace, Providers, Switch, Models, Fork, etc.), but the details are not polished, and edge cases are not handled. Any Pull Requests are welcome.

PS: Development is mainly driven by GLM 5.3, with optimization and inspection relying on Kimi K3.

@rhlsthrm

[MhAhmadAli]

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 handleTui-only registration @Mustaqeem66 documented for /collab, /join and /leave — it never asks for collab at all. It also means it has no path to a session it did not spawn, since RPC is one child process per session and switch_session swaps which session a process drives rather than multiplexing.

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. RpcClient drops extension_ui_request (its listener set is private and populated only inside login()) and command_output (not an agent event, so it matches no guard). Approval prompts need the first, builtin slash command output needs the second, and both are additive.

One more finding for anyone else building on RPC, since it cost me a while to pin down: a dialog awaited from session_start cannot be answered at all. readRpcInputFrames only starts consuming stdin after startup finishes, so the response a host writes sits unread in the pipe and the handshake times out with a message that says nothing about the cause. Raising a dialog during session_start without awaiting it is fine. Everything I know about that is measured — I wrote the answer and watched it never get read — rather than inferred.

Happy to fold work in whichever direction is most useful once @can1357 makes the scope call.

[materemias]

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:

• start new sessions from the phone,
• list and continue historical sessions across all projects,
• take over and continue sessions still running in the terminal. An omp extension keeps the terminal session updated, so jumping between terminal and phone mid-session works both ways,
• model switching, rich transcript rendering, images, approvals.

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.

[pstayets]

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. shell wrapping any command prints a live browser link, watch and type from any device, the session survives disconnects and dies with the task. It will not give you the synced session list across machines this thread is designing, shell list is per-host, so treat it as the stopgap while the registry work matures. MIT, single Go binary, macOS and Linux.

[alphastorm]

OMP already has native /collab: docs. omp-session-gateway uses that functionality directly rather than replacing it.

[pstayets]

Fair correction, thanks. I had missed that /collab already prints a browser deep link with read-only and custom relay support, that covers the OMP case better than a generic PTY wrapper, native rendering included. shell.online stays useful for the non-OMP processes running next to it, builds and other CLIs, but for OMP sessions /collab is the right answer.

[rhlsthrm]

The main point in this thread is that each /collab session has a unique URL. I am looking for a "Claude/ChatGPT app" like experience where I can log into one app and see all my sessions in one place.

[HarshalRathore]

How about using t3 code desktop app stripping away there core harness orchestrating engine and replacing that with omp? OMP doesn't follow one backend multiple client architecture which kind of limits a lot of things as I can see it

[sorphwer]

@materemias @alphastorm @pstayets @MhAhmadAli

Thanks for your time, as a summary, I personally think that:

1. Only two basic features should be included natively in OMP : a) Auto enable collab b) List all collab
2. With these two features shipped, the community can develop any 3rd party services to provide custom remote access and session management. I believe anyone can make use of these 2 features and build their own remote session bridge/manager easily
3. OMP does not need to ship a full experience about remote session access / management, as an alternative compared with other project you mentioned.

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.

[pstayets]

Agree with the shape, and I would keep it exactly that small. Two details make or break whether third parties can actually build on it:

1. "List all collab" should return machine-readable rows, not just URLs: a stable session id, the deep link, the host name, whether it is read-only, and whether the host is currently connected. That last field is what every bridge needs and none can get from outside.
2. Auto-enable should be a config flag with an environment override, so a bridge can turn it on for sessions it launches without touching the user's global config.

With those two, the cross-machine list people are asking for is a hundred-line bridge polling each host, and OMP never has to own a remote product. Disclosure as before, I work on Pilot Protocol, which develops shell.online, and I would rather build against a surface like that than have every harness ship its own remote stack.

[alphastorm]

Broadly agree. One refinement: "list all collab" is really two contracts:

1. enumerate non-capability metadata, suitable for polling/watching;
2. acquire View or Control for one exact session generation, only after explicit user action.

OMP should own those primitives and their lifecycle: one controller shared by /collab and opt-in off | view | control auto-start; publish/update/revoke; revoke generation N before publishing N+1; bounded crash cleanup.

It does not need to own the daemon, remote authentication, transport, or PWA/mobile UX. That is the split we run out-of-tree with omp-session-gateway: OMP owns collaboration lifecycle/publication; the gateway owns aggregation and UX. This avoids process scraping and competing CollabHost owners.

So: yes to native primitives; no need for OMP to ship a complete Claude Remote product. I would only soften "easily": generation and capability boundaries need to be part of the native contract, because that is where most correctness and security failures occur.

(and just to reiterate if helpful, my previous offer to upstream any of this work still stands, just let me know: #6460 (comment))

Thanks for driving this @sorphwer! 🙏

[materemias]

One thing what's missing for me to be able to initiate new sessions remotely.

[HarshalRathore]

I really like omp but it's limiting me because I have stick to my laptop to use it, terminal on mobile is not a great experience and not usable at least for me

[sorphwer]

One thing what's missing for me to be able to initiate new sessions remotely.

This is a question that locates in another layer. Even in Claude Code you cannot initiate this. You need a 'daemon service' that runs in your machine and it has permission to call bash omp.

In Claude Ecosystem you need 'Dispatch' to do this but the experience is really bad, or in other ecosystem you always needs a running service to do this.

[alphastorm]

#9031 is merged (598109394f on main; ships in the release after v18.1.16). It went in with retention as the default, not a setting: an ask raised with zero peers is kept and delivered to the next writer that joins. One fewer decision for #6171.

Since then, three findings verified against current main, offered as design input for #6354/#6171:

1. Late/duplicate responses are still dropped silently. #handleUiResponse (host.ts:460) is #pendingUi.get(reqId)?.settle(…). A writer that reconnects after the request settled missed the ui-request-end broadcast, re-sends, and gets nothing back, so its "Sending…" never converges. Phones reconnect constantly. Fix is a targeted idempotent ui-request-end to the responder — fix(collab): retain host UI requests until a writer joins #9031-sized; happy to send it.
2. A registry publisher needs diagnosable state. Second instance of the class behind my feat(collab): list active local host sessions #6354 note: ours latched off on a transient EACCES reading its token, and three live sessions vanished from the directory for the rest of the process while daemon, socket and doctor all reported healthy. Fix: latch only on deterministic violations (non-IPC endpoint, world-readable socket), retry everything else with backoff, and expose publishing | retrying(N) | disabled: <reason> in /collab status. An induced EACCES then recovers in ~20 s in-process.
3. Auto-enroll ordering. Start collab before extension session_start hooks, or a dialog raised there isn't retained (cf. @MhAhmadAli's RPC finding). Keep teardown under the existing bounded slow-close timer, or Closing session… regresses — interactive-mode-still-closing.test.ts caught that in our reroll.

For the row contract @pstayets asked about: key cards by a random per-process instanceId (PIDs recycle) plus generation; title/cwd/model refresh in place without rotating links; publish inputRequired only while a serializable ask (ask/select/confirm/input/editor) is pending for a writable guest — callback/slider/prompt-style UI must stay local. For @materemias's Step 2: collab-web writes the capability to location.hash (app.tsx:59), so a directory/multi-room client needs an in-memory bootstrap entry; we carry a small patch. Images already cross the wire ({ t: "prompt", images? }) — phone photos needed no protocol change.

Pin is v18.1.14 now (fourth since July; #9031 itself needed a rebase after 227 upstream commits). Provenance: patches/oh-my-pi/README.md.

[alphastorm]

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:

• @sorphwer for starting this discussion and their work on feat(collab): list active local host sessions #6354
• @materemias for their work on feat(collab-web): global remote toggle — auto-enroll all sessions into an authenticated web UI with a session side panel #6171
• and all the other contributors for their input/feedback in this thread 🥰

[materemias]

nice work @alphastorm , do you plan to update https://github.com/alphastorm/omp-session-gateway so it doesnt rely on the patched omp any more?

[alphastorm]

thanks @materemias, yep I plan to do that today!

[H4vC]

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.

[sorphwer]

@H4vC @alphastorm Thanks a lot for following up, let's keep in touch in Discord :)

[KamijoToma]

hi, I wrote a omp-hub app that wraps the session discovery and enhances /collab experience with TUI-only commands like /rewind /new, just like the excellent work from omp-session-gate.

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

[sorphwer]

glad to know if any omp feature shipped in this dicussion helps you