Request: Graphical User Interface (desktop + web) on top of oh-my-pi

[HarshalRathore]

Feature Request: Graphical User Interface for oh-my-pi

The Ask

OMP is a terminal-driven agent harness — powerful, scriptable, hash-anchored. But the TUI is the only face it has. Unlike peers in the space (OpenCode, Codex CLI, Cursor), there is no graphical interface layer.

Request: a browser-based GUI (single codebase, renders as both a web app and a desktop app via Tauri/Electron) that wraps the OMP agent core. Think of it as omp daemon exposing a local API, with a nice React frontend consuming it.

Why

Product	Interface	Model
OpenCode	Web UI (localhost:5173) + Desktop	Runs opencode-go as a backend, frontend talks to it via API
Codex CLI	Web UI (localhost:7172) + Terminal fallback	Same pattern — local daemon + browser UI
Cursor	Standalone desktop app	Tightly integrated editor
OMP	TUI only	No graphical layer exists

The pattern is proven: a local agent daemon + a browser UI gives you both a desktop app (e.g. Electron/Tauri wrapping the web UI) and a web app (just open the browser) from one codebase.

Suggested Approach

1. Daemon mode — omp serve (or omp daemon) starts the agent runtime as an HTTP/WebSocket server on a local port, exposing a simple JSON API for: starting sessions, sending messages, streaming responses, managing files.
2. Web UI — A standalone frontend (React, Svelte, or similar) consuming that API.
   • Desktop: wrap it in Tauri → native window, system tray, notifications
   • Web: serve the same build from the daemon, open http://localhost:<port>
3. Share the TUI code where possible — the terminal emulator, markdown renderer, and keybindings from pi-tui could be repurposed for a browser-based terminal component.

Minimum Viable GUI

Not asking for a full IDE. The MVP could be:

• Chat pane — message list with streaming, markdown rendering, syntax-highlighted code blocks, image display
• Input area — multi-line editor with history, paste support, @-mentions for files
• Session list — sidebar showing open/recent sessions, click to switch
• File viewer — inline diff display, file tree
• Settings panel — provider config, model selection, keybindings
• System tray — background daemon, click to open

Nice-to-have GUI Details

• Dark/light theme matching system preference
• Split-pane view: code diff on one side, chat on the other
• Drag-and-drop file attachment
• Rich rendering of errors, diffs, and Mermaid diagrams (already done in TUI)
• Desktop notifications (already done in TUI — pi-tui has desktop-notify.ts)

Existing Assets to Reuse

OMP already has most of the heavy lifting done in @oh-my-pi/* packages:

Package	What it provides	GUI reuse
pi-tui	Markdown renderer, image display, keybindings, autocomplete, fuzzy search	Port markdown/syntax rendering to web
pi-coding-agent	Session management, tool execution, agent loop	The core — expose via API
pi-mnemopi	Long-term memory	Settings/knowledge panel
omp-stats	Analytics	Usage dashboard

Prior Art Links

• OpenCode web UI: https://github.com/m/opencode (the React frontend pattern)
• Codex CLI web UI: https://github.com/openai/codex (browser-based chat)
• Tauri: https://v2.tauri.app (Rust shell for web → desktop)
• Continue.dev: https://github.com/continuedev/continue (VSCode extension as GUI, different approach)

Why Now

OMP is already competitive on the agent side (subagents, LSP, AST edits, hooks, extensions). The missing piece is a graphical interface that lowers the barrier for less terminal-native users and gives a visual workspace for diff review, multi-file editing, and session management. A web-based GUI also enables remote usage (SSH-forward the port, use from a tablet).

[roboomp]

This proposes a long-lived OMP service that owns agent sessions and exposes a streaming protocol, with one browser client reused for local web and a desktop shell. The architecture is feasible: packages/coding-agent/src/sdk.ts already exposes createAgentSession, and packages/stats/src/server.ts provides an in-repo precedent for serving an embedded browser client plus JSON endpoints.

The main scope is the daemon contract, not the React/Tauri shell: session lifecycle and reconnection, ordered agent/tool events, approval prompts, cancellation, concurrent workspaces, file-access boundaries, and persistence all need stable protocol semantics. pi-tui components are terminal renderers, so the web client can share event/data models and interaction semantics, but markdown, images, input, and key handling would need browser-native rendering rather than direct component reuse. Remote access also changes the security model substantially because the agent can read files and execute tools; a localhost-only listener is much safer than treating SSH-forwarded or LAN access as an incidental feature.

Before implementation, maintainers need to decide:

• Is the first target localhost-only web, a desktop package, or both? Which desktop runtime should be supported initially?
• Is the daemon one process per workspace or a multi-workspace service, and who owns process startup/shutdown?
• Is remote access in scope? If so, what authentication, origin/CSRF policy, and filesystem/tool authorization model is required?
• Which session operations and event types become a supported public API, including reconnect/replay and human approval flows?
• Does the initial UI stop at chat/session/diff review, or also own provider credentials, extension UI, and arbitrary file editing?

A practical first slice would be a localhost-only daemon with one workspace, explicit session create/resume/send/cancel endpoints, an ordered replayable event stream, and a browser chat/diff client. Desktop packaging, system tray, remote access, and broader settings management can then build on a protocol proven by that slice rather than defining the protocol around shell-specific needs.

[vitalNohj]

Have you seen herdr?

[HarshalRathore]

Have you seen herdr?

That's no graphical user interface just another terminal multiplexer with toping of agents first I already use tmux what I meant for something like codex Desktop app(unfortunately it's not OSS) or t3 code desktop app or opencode desktop app or zcode desktop app

[roboomp]

Understood — the ask is a genuine graphical desktop/web client (in the shape of the opencode/Codex desktop apps), not a terminal multiplexer wrapping agents. That matches the daemon-plus-browser-client architecture in the original request, and the scope questions above (localhost-only vs remote, single vs multi-workspace, which session operations become a supported protocol, desktop packaging target) still need a maintainer decision before any implementation. Keeping this as enhancement pending that call.

[Mr54233]

I think we still need a VS Code extension GUI.

[roboomp]

A VS Code extension is a distinct delivery vector from the standalone desktop/web client this issue tracks — it's the Continue.dev-style approach already listed under prior art. It could reuse the same daemon protocol (session create/resume/send/cancel + an ordered replayable event stream) as a second front-end, but the editor-integration surface (webview UI, editor/diff APIs, extension activation lifecycle) is largely separate work from a Tauri/browser shell. Which front-ends ship, and in what order, remains a maintainer scope decision; keeping this as enhancement pending that call.

[XGntsl]

expected

[yhcedpn]

#8813 is closed and feature request about GUI of oh-my-pi is here.

My opinion is providing a CodexApp-like GUI. the left is session list, the middle is current session, the right is workspace.