OmpOS: a chat-style workspace built around the omp engine

OmpOS is a chat-style agent workspace whose engine is omp. It is for developers who want one workspace for omp that works from a browser, a desktop, or a phone. The foundation is in place, and the runtime that launches omp sessions is planned.

At a glance

The README describes a desktop harness that speaks ACP, a protocol that uses JSON-RPC 2.0 over standard input and output through omp acp. It also describes a Blazor WebAssembly web app, .NET MAUI shells for macOS, Windows, iOS, and Android, and one ASP.NET Core backend. MAUI is Microsoft's .NET Multi-platform App UI framework. This page separates what the repository contains from what the README describes.

At a glance

• The problem is CLI-native programming on any surface. The omp engine runs on the command line, and people want to start the same work from any screen.
• The README says a prompt typed on any surface becomes an omp session. This path is planned, not built.
• The design reaches omp through omp acp and omp --mode rpc, over standard input and output. No code launches either process.
• A planned event log numbers each event, so a client can resume a stream. The event contract exists; the log does not.
• The repository has contracts, architecture and contract tests, CI and container configuration, and a Blazor WebAssembly template.

A command-line engine works well in a terminal. Starting the same work from a browser or a phone needs a server, a stream of events, and a record of what the engine did. OmpOS is meant to supply those parts. The repository holds shared shapes for them. It does not yet hold the code that runs them.

The README also says streamed output renders as Generative UI, meaning structured, interactive blocks rather than plain text. The block contracts exist in src/OmpOS.Contracts. The UI project, src/OmpOS.UI, holds a placeholder marker class and an imports file.

This page does not compare OmpOS with other products.

• Community ACP packages. The decision record rejects them for .NET. It says the team wanted owned components, and none of the packages covers omp's RPC mode.
• Generic chat clients. The record rejects wrapping omp as a generic chat client. It says that approach hides the sequence-numbered event model that resume depends on.
• Raw HTML from agent output. The record rejects rendering agent output as raw HTML, because the output is untrusted. The planned Markdown renderer, Markdig, runs with HTML disabled.

Each rejected option is recorded with its reason. None of those choices has been tested by running code, because the runtime does not exist yet.

OmpOS starts with contracts. The src/OmpOS.Contracts project holds the shapes that the other layers share: sessions, intents, stream events, UI blocks, sandbox descriptors, and workflow runs. It has 37 C# source files and declares contract version 1.0.0. Both figures are static counts.

Architecture tests check the rules between projects. A layer map places the contracts at the base, and the web app and API hosts at the top. Nine architecture test attributes, a static count, cover those rules.

The engine integration is planned as two owned clients: one for omp's ACP mode and one for its RPC mode. Neither client exists yet. Every planned behaviour on this page is marked Planned. Every intended outcome is marked Projected.

The planned flow has five stages. Only the contract shapes for them exist today.

1. Parse. The planned prompt parser in src/OmpOS.Parser turns each prompt string into exactly one intent envelope and keeps the raw text.
2. Run. The planned session service in src/OmpOS.Sessions sends that envelope to a harness. The planned ACP and RPC harnesses live in src/OmpOS.Harness.Acp and src/OmpOS.Harness.Rpc.
3. Record. Each event from omp gets the next sequence number and is appended to the session log. The event shape is in src/OmpOS.Contracts/Streaming/StreamEvent.cs.
4. Stream. The planned API in services/OmpOS.Api sends events to clients as server-sent events (SSE), a one-way stream over HTTP. The sequence number is the event ID, so a client can ask for events after the last one it saw.
5. Render. The planned shared UI in src/OmpOS.UI maps each UI block to a view. Blocks it does not recognize fall back to a generic view.

Example workflow (illustrative scenario)

This scenario is invented to show how the planned modules would connect. It describes no real session, and nothing in the repository runs it.

A developer opens the browser surface and types a prompt asking for one change in a source file. In the planned design, the parser in src/OmpOS.Parser wraps that text in an intent envelope and keeps the raw text unchanged. The session service in src/OmpOS.Sessions opens a session and hands the envelope to the ACP harness in src/OmpOS.Harness.Acp. That harness would start omp acp over standard input and output. No launch code exists, so this step is planned only.

Each event from omp is appended to the session log with the next sequence number, as src/OmpOS.Contracts/Streaming/StreamEvent.cs defines. When omp asks to run a tool, the planned approval hook denies the request by default. Halfway through the run, the developer's connection drops. On reconnect, the browser asks the API for events after the last sequence number it received, and the planned stream sends the rest. The change then appears as a block in the view.

This section states what is signed, which operations use keys the operator holds, and what runs off-chain.

Off-chain. OmpOS operations are off-chain. The product code has no wallet, chain, Web3, or blockchain code or dependency, and no signing or signature-verification code. Vendored front-end library files contain matching words, but they are not product code.

Signed operations. None. No operation in the foundation projects is signed by a user.

Operator-held credentials. The CI workflow refers to operator-held secrets. The repository holds no secret values.

Local stack. The Temporal development container publishes its two ports on the loopback address only. Its start command runs the dev server without authentication configuration. It starts only when the operator uses the workflows profile.

Login. No login, session, or authentication code exists. The open-questions register records a planned single development user for the auth boundary (OQ-26).

Approvals. The planned approval hook denies by default. The planned rule is that the hook may only deny earlier, never grant more. No hook code exists.

Installer. The bootstrap script downloads the .NET installer over HTTPS without a pinned digest. The open-questions register tracks this as an open item (OQ-27).

Container runtime. Podman is the only supported container runtime. A repository test checks that Docker tooling is absent from the bootstrap, CI, and compose files.

Hosting. The repository tracks no Vercel or Railway configuration. The README names both as hosting targets.

Status is taken from commit 14ca062 on the feat/ompos-scaffold branch. Later commits on that branch change planning documents only.

Foundation automated checks are in place and human review is pending. The verification report lists three items for human review, and none has been observed yet: a green remote CI run, the macOS job for the native shell, and a compose config check with the real podman-compose binary. No code launches the omp engine.

The planning files disagree on phase status. .planning/ROADMAP.md marks no phase complete and shows Phase 1 in progress, with three of three plans checked. .planning/STATE.md records one completed phase. The Phase 1 verification report, .planning/phases/01-foundation/01-VERIFICATION.md, has the status human_needed.

Implemented

• Contract layer: 37 C# source files and contract version 1.0.0, in src/OmpOS.Contracts.
• Architecture tests for layer rules and the project graph, in tests/OmpOS.ArchitectureTests.
• Contract tests for versioning, serialization, streaming, and UI blocks, in tests/OmpOS.Contracts.Tests.
• CI workflow with build, test, format, vulnerable-package, secret-scan, and compose steps in one job, in .github/workflows/ci.yml. No remote run has been observed.
• Pinned .NET SDK 10.0.402, in global.json.
• Local Temporal development container behind the workflows profile, in deploy/compose.yaml. Its config has not been checked with the real podman-compose binary.
• Open-questions register with 27 rows, 17 of them open, in docs/open-questions.md.

In progress

• Prompt parser, in src/OmpOS.Parser. Scaffold only, with a placeholder marker class. Phase 2, Core.
• Harness abstractions and clients, in src/OmpOS.Harness.Abstractions, src/OmpOS.Harness.Acp, src/OmpOS.Harness.Rpc, and src/OmpOS.Harness.InMemory. Scaffold only. Phase 2, Core.
• Session service, in src/OmpOS.Sessions. Scaffold only. Phase 2, Core.
• API host, in services/OmpOS.Api. A class library with no endpoints. Phase 2, Core.
• Shared chat UI, in src/OmpOS.UI. Scaffold only. Phase 4, Surfaces.
• Generative UI renderer, in src/OmpOS.GenUi. Scaffold only. Phase 4, Surfaces.
• Web head, in apps/OmpOS.Web. A Blazor WebAssembly template with a router shell and no product UI. Phase 4, Surfaces.
• Sandbox, in src/OmpOS.Sandbox and src/OmpOS.Sandbox.Abstractions. Scaffold only. Phase 3, Platform.
• Workflows, in src/OmpOS.Workflows and services/OmpOS.Workflows.Worker. Scaffold only. Phase 3, Platform.

Planned

• Adapters that launch omp acp and omp --mode rpc over standard input and output, plus the approval hook. Phase 2, Core. Cited in .planning/ROADMAP.md.
• An append-only, sequence-numbered session log for resume. The event contract exists in src/OmpOS.Contracts/Streaming/StreamEvent.cs; the log does not. Phase 2, Core. Cited in .planning/ROADMAP.md.
• API endpoints for sessions and prompts, with server-sent events and resume. Phase 2, Core. Cited in .planning/ROADMAP.md.
• An approval hook that denies by default. Phase 2, Core. Cited in .planning/STATE.md.
• Sandbox providers: a fake provider and a local podman-compose provider, plus vendor stubs. Phase 3, Platform. Cited in .planning/ROADMAP.md.
• Durable workflows: a direct session runner, with an optional Temporal worker behind a flag. Phase 3, Platform. Cited in .planning/ROADMAP.md.
• Web head hosted on Vercel. Phase 4, Surfaces. Cited in .planning/ROADMAP.md.
• Native shells for macOS, Windows, iOS, and Android, built with MAUI. Phase 4, Surfaces. Cited in .planning/ROADMAP.md and README.md.
• Backend hosted on Railway. Phase 2, Core, which builds the API. .planning/ROADMAP.md does not schedule a hosting step. Cited in README.md.
• Clean-clone bootstrap test and finished docs. Phase 5, Verify & Handoff. Cited in .planning/ROADMAP.md.

Maturity, by static count (nothing was built or run for this page): 37 contract source files; 27 test attributes in 8 test files; 13 runtime projects with no product code beyond a placeholder marker class; one Blazor WebAssembly template.

• Projected: One prompt typed on any surface becomes one omp session, and its events stream as they arrive. Basis: the stated behaviour in README.md and the Phase 2 goal in .planning/ROADMAP.md.
• Projected: A stored session can be replayed to rebuild the same block tree. Basis: the Phase 2 replay criterion in .planning/ROADMAP.md.
• Projected: A tool request waits for a decision, and the default answer is no. Basis: the Phase 2 approval criterion in .planning/ROADMAP.md and the planned rule in .planning/STATE.md.
• Projected: A sandboxed run tears down its resources, even when the run fails. Basis: the Phase 3 criteria in .planning/ROADMAP.md.
• Projected: Desktop, mobile, and web heads show one chat surface. Basis: the Phase 4 goal and its shared-UI criterion in .planning/ROADMAP.md.

Is OmpOS available to use today?

No. The repository has a contract layer, architecture and contract tests, CI and container configuration, and a Blazor WebAssembly template. Its runtime projects hold placeholder marker classes, and no code launches the omp engine. Foundation automated checks are in place, and human review is pending.

Does OmpOS run on the command line?

The design reaches omp through its command-line modes: omp acp over stdio, and omp --mode rpc. The adapter that launches those processes is planned for the Core phase. It is not built, so no command-line session can run from this repository today.

Does OmpOS use a blockchain, wallet, or user signing?

No. The foundation projects contain no wallet, blockchain, or Web3 code, no signing code, and no user-signed operation. Its operations are off-chain. The repository holds no operator-held key values, and the approval hook that would gate tool requests is planned, not built.

Where will it be hosted?

The README names Vercel for the web surface and Railway for the backend. The repository has no deployment configuration for either yet. Its only deployment file is a local podman-compose stack that starts a Temporal development server under the workflows profile.

Request a technical briefing through the site's contact page, and ask for the status list in writing.

Paths are relative to the ompos repository unless noted.

• README.md
• .planning/ROADMAP.md
• .planning/STATE.md
• .planning/phases/01-foundation/01-VERIFICATION.md
• docs/decisions/ADR-0002-surface-technology.md
• docs/open-questions.md
• bootstrap.sh
• src/OmpOS.Contracts
• src/OmpOS.Contracts/Streaming/StreamEvent.cs
• src/OmpOS.Parser
• src/OmpOS.Sessions
• src/OmpOS.Harness.Abstractions
• src/OmpOS.Harness.Acp
• src/OmpOS.Harness.Rpc
• src/OmpOS.Harness.InMemory
• src/OmpOS.UI
• src/OmpOS.GenUi
• src/OmpOS.Sandbox
• src/OmpOS.Sandbox.Abstractions
• src/OmpOS.Workflows
• services/OmpOS.Api
• services/OmpOS.Workflows.Worker
• apps/OmpOS.Web
• tests/OmpOS.ArchitectureTests
• tests/OmpOS.Contracts.Tests
• .github/workflows/ci.yml
• global.json
• deploy/compose.yaml