Omnigent: a meta-harness for running Claude Code, Codex and Cursor side by side

The problem Omnigent is aimed at: too many agent CLIs, no shared control plane

Each coding agent ships its own terminal, its own session model and its own approval prompts. If you use Claude Code for one repository and Codex for another, nothing is shared: not the conversation history, not the spend cap, not the record of which tool calls were approved. Omnigent's answer is to sit above those CLIs as a meta-harness. The README describes a common orchestration layer over Claude Code, Codex, Cursor, OpenCode, Hermes, Pi and agents you define yourself in YAML, so a session can mix harnesses and you can ask one agent to review another's work.

The audience is narrower than the tagline suggests. This is for engineers and platform teams who already pay for or run several agent CLIs and want governance over them, and for teams that need sessions to survive a device change. The README's own framing is that sessions follow you from terminal to browser to phone, with messages, sub-agents, terminals and files staying in sync. A single-agent user gets little from the extra layer.

How the meta-harness layer works: a server, sessions, and per-harness wrappers

The repository layout shows the split. A Python package lives in omnigent/, an HTTP surface is described by openapi.json, a pnpm workspace sits in web/ with its own package.json, and separate SDK packages (omnigent-client, omnigent-ui-sdk) are version-locked to the main package in pyproject.toml. That is a client-server design: an omnigent server process owns session state, and terminals, the browser UI and the SDKs are clients of it.

Harnesses attach in two modes. SDK-based harnesses run through omnigent run <agent.yaml>, where an agent is a declarative YAML file; the examples/ directory contains several, such as examples/kimi_hello.yaml and directories like examples/deep-research/ and examples/sentinel/. Native harnesses instead get a terminal wrapper: omnigent claude, omnigent codex, omnigent cursor, omnigent hermes, omnigent kiro and omnigent pi, each backed by tmux and a PTY. On Linux those wrappers wrap the agent terminal in a bubblewrap (bwrap) OS sandbox, and the README states that isolation is mandatory there, so a missing bwrap binary makes those terminals fail to start. macOS uses the built-in seatbelt sandbox instead.

Sandboxing for whole sessions is separate and provider-based. Sessions can run in disposable Modal, Daytona, Blaxel, Islo, E2B, CoreWeave, Kubernetes, OpenShell, Boxlite or Databricks sandboxes, launched from the CLI or provisioned by the server per session, which the README calls managed hosts. Policies are the third control: they can pause for approval before risky actions, cap spend, or limit which tools an agent reaches, and they apply to the whole server, one agent, or a single chat.

Installing Omnigent and starting a first session

The README gives a one-line bootstrap that installs Omnigent and its prerequisites. Run it in a POSIX shell; on Windows it does not apply, and the README points Windows users at a direct uv install instead.

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh

Optional integrations are passed as extras to the same installer. The README lists model-provider extras (databricks, bedrock, vertex), sandbox extras (modal, daytona, blaxel, boxlite, cwsandbox, e2b, openshell, kubernetes), SDK harness extras (antigravity, copilot, cursor, agents-sdk) and storage extras (s3, hindsight).

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --extra modal,e2b

If you prefer to manage the environment yourself, the README requires Python 3.12 or newer and shows uv and pip forms, with the same extras syntax. Homebrew and a direct git install are also documented.

uv tool install omnigent
uv tool install "omnigent[databricks,modal]"

For a first real use, the declarative path is the shortest. Point the run command at one of the YAML agents shipped in examples/. The README shows the form omnigent run <agent.yaml>; substitute a file from the examples/ directory such as examples/kimi_hello.yaml, and expect the session to appear in the terminal and, if the server is running, in the web UI as well. If you would rather wrap an existing CLI, omnigent claude opens the native terminal wrapper, which needs tmux and, on Linux, bwrap.

uv tool install --python 3.12 omnigent
omnigent run examples/kimi_hello.yaml

Updating is handled by the CLI itself. The README states Omnigent shows a one-line notice once per release when a newer version is on PyPI, and that omni upgrade detects how you installed it before updating.

Where Omnigent is the wrong tool: Windows, isolation, and alpha churn

Windows is the clearest limitation, and the README is explicit about it rather than burying it. Omnigent runs natively on Windows in what the documentation calls a degraded mode. The install_oss.sh bootstrap is POSIX-only, so Windows users install with uv directly. What works is the server, the web UI and the SDK-based harnesses, with agents contained by a Windows Job Object for process-tree control and resource limits.

What does not work is more interesting. The native omnigent claude, omnigent codex and omnigent cursor tmux/PTY wrappers are unavailable on Windows; the README directs those users to an SDK harness, the web UI, or Linux/macOS/WSL. Filesystem and network sandboxing through bwrap or seatbelt is also unavailable, along with the L7 egress proxy. The Job Object backend, in the README's words, does not isolate the filesystem or network. So if your threat model includes an agent reading files outside its working directory or making outbound calls, native Windows is not the platform for it.

Two smaller constraints matter in practice. The toolchain requires uv and git, plus Node.js 22 LTS or newer with npm for the coding-harness CLIs and pnpm for the web UI, which is a heavier footprint than a single-agent CLI. And the project's own metadata in pyproject.toml classifies it as Development Status 3 - Alpha, with the package version at 0.14.0.dev0 while the most recent release is v0.11.0. Three releases landed in August 2026, which tells you the surface is still moving. The README also does not document rollback for a failed upgrade, so treat omni upgrade as one-way until you have checked the changelog yourself.

Omnigent compared with running OpenCode or OpenClaw directly

The honest comparison is not Omnigent versus another framework, because Omnigent does not replace the agents. It wraps them. OpenCode and OpenClaw appear in the README as harnesses Omnigent can drive, alongside Claude Code, Codex, Cursor, Hermes and Pi, and the repository contains an OpenClaw integration that stores a wrapped acpx registry as JSON5. If you use one of those tools alone, you already have its session model, its permission prompts and its model configuration. Omnigent adds a layer above that: shared sessions across harnesses, server-scoped policies, and remote sandbox providers.

The difference in approach shows up in what you give up. A single harness keeps one configuration file and one update path; Omnigent keeps a server, a client SDK, a web workspace and a policy layer that all move together. The upside is that swapping from one harness to another does not mean rewriting your prompts or your approval rules, and that a policy written once applies to the whole server rather than to one CLI's settings. The downside is a second system to operate, and a second place for a version mismatch to appear: pyproject.toml pins omnigent-client and omnigent-ui-sdk to the exact same version as the main package, and release tooling verifies those pins against the release tag, so mixing versions across the three is not a supported path.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-08-25, the same day v0.11.0 was released. That is recent enough that the project is clearly being worked on, and the CHANGELOG.md at the repository root is where release notes live. The cadence through August 2026 was roughly weekly, which is fast for something you would put in front of a team.

Licensing is Apache-2.0, with a NOTICE file alongside the LICENSE and a DCO file indicating a developer certificate of origin requirement for contributions. Apache-2.0 is permissive and includes an explicit patent grant, which matters if you are embedding the client SDK in something you ship. This is a description of the licence text, not legal advice; the SDK packages and the web workspace ship under the same repository, but check individual package metadata before redistributing.

Upgrade cost is the part teams underestimate. The README documents omni upgrade as detecting your install method, and setup.py generates a _build_info.py at wheel build time so the CLI's update check can tell when an installed build is stale without consulting git or hitting a remote endpoint. That part is tidy. What the README does not document is a rollback path, and with three releases in one month and a package version ahead of the released tag, pinning an exact version in your own environment is the safer default than tracking latest.

Editorial conclusion

Adopt Omnigent if you already run more than one coding agent and want a single session, policy and sandbox layer over them, and if your machines are Linux or macOS. Skip it if you need native Windows terminal wrappers, filesystem or network isolation on Windows, or a stable API: pyproject.toml classifies the project as Development Status 3 - Alpha, and the release cadence (v0.9.0 on 2026-08-11, v0.10.0 on 2026-08-19, v0.11.0 on 2026-08-25) means interfaces can move between versions. Verify first that your target harness is listed in the README's supported set, that tmux is present on any host where you plan to use the omnigent <harness> wrappers, and that bwrap is installed on Linux, because the README states those terminals fail to start without it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes