Omnigent is a control plane for the coding agents you already use. Instead of running Claude Code in one terminal and Codex in another, you run them through Omnigent, which gives you one session where multiple agents can work, supervise each other, and stay governed by policies you set. The project calls itself a meta-harness, and that word is the whole idea: it sits one level above the individual agent runtimes (Claude Code, Codex, Cursor, Pi, the OpenAI agents SDK, and your own YAML-defined agents) and gives them a shared orchestration, collaboration, and governance layer.

It is Apache-2.0, written in Python (3.12+), and you should know up front that it is brand new: the repo was created in June 2026 and is still labeled alpha. The star count climbed fast, but you are looking at very early software.

What the meta-harness actually buys you

If you only ever run one agent by hand, Omnigent is overhead. Its value shows up in three situations the README demonstrates well:

Multi-agent supervision. The example agent Polly is a tech lead who writes no code herself: she plans, delegates work to coding sub-agents (Claude Code, Codex, or Pi) in parallel git worktrees, then routes each diff to a reviewer from a different vendor than the one that wrote it. Cross-vendor review is a real technique for catching model-specific blind spots, and Omnigent makes it a config rather than a custom script. The other example, Debby, sends every question to both a Claude head and a GPT head and lays the answers side by side, with a /debate mode where they critique each other.

Governance. Policies decide what an agent may do (run shell, edit files, spend tokens) and either allow, block, or pause for your approval. They stack across three levels: server-wide, per-agent, and per-session, with the stricter session rules checked first. Spend caps and tool-call limits ship as builtins, and you can add one conversationally (“add a policy that asks me before running shell commands”). For anyone running agents with real permissions, this is the part worth the install.

Cross-device collaboration. A session follows you from terminal to browser to phone, and you can share it so a teammate watches live, co-drives on your machine, or forks the conversation to continue on their own. There is multi-user auth, invite-only signup, and OIDC login (Google, GitHub, Okta, Microsoft) for deployed servers.

Install

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh
# or
uv tool install omnigent        # pip install "omnigent" also works
brew install omnigent-ai/tap/omnigent

Then run omnigent (aliased to omni) to pick a model and start a session, which also opens a local web UI at http://localhost:6767. On first run it reuses credentials already in your environment, an ANTHROPIC_API_KEY/OPENAI_API_KEY or a logged-in claude/codex CLI. Models come from four credential kinds: vendor API keys, Claude/ChatGPT subscriptions via the official CLIs, any OpenAI- or Anthropic-compatible gateway (OpenRouter, LiteLLM, Ollama, vLLM, Azure), and Databricks.

The platform reality nobody mentions until it breaks

Omnigent leans hard on OS-level sandboxing, and that makes its prerequisites stricter than a typical pip package. You need uv, git, Node.js 22+, and tmux. On Linux, bubblewrap (bwrap) is mandatory: the native Claude/Codex/Pi wrappers isolate each agent terminal in a bwrap sandbox, so without it those terminals fail to start. macOS uses the built-in seatbelt sandbox and needs nothing extra.

Windows is the gap. Native Windows support is an open question in the issue tracker, and the practical answer today is to run it under WSL2. If you are on Windows, plan for that rather than expecting a native install.

There is also a known auth bug worth flagging: server-managed cloud sandboxes have been reported to fail under native OIDC/accounts auth because the runner is not authenticated. If you are deploying with OIDC and managed hosts together, check that issue before you rely on it.

Cloud sandboxes and deploy

You do not need a laptop online. Sessions can run in disposable Modal, Daytona, or Islo sandboxes, launched from the CLI or provisioned per session by the server (managed hosts). For a stable URL, one docker compose up runs the server on any VPS or home server, with Render, Fly.io, Railway, Hugging Face Spaces, and Modal all documented.

Alternatives

ProjectWhat it isHow it differs
omnigent-ai/omnigentMeta-harness over many agent runtimesOrchestration + governance + collab across vendors
earendil-works/piAn agent harnessOne of the runtimes Omnigent can drive
Kilo-Org/kilocodeA single coding agent across IDEsA harness itself, with its own model marketplace
obra/superpowersA skills framework for agentsExtends one agent rather than orchestrating many

The clean distinction: kilocode, pi, and superpowers each make one agent better, while Omnigent’s job is to conduct several of them and keep them on a leash.

FAQ

Is omnigent free? Yes. It is open source under Apache-2.0. You bring your own model credentials (API keys, a Claude/ChatGPT subscription, a gateway, or Databricks), so your only cost is model usage.

What is a meta-harness? It is an orchestration layer above individual agent runtimes. Omnigent runs Claude Code, Codex, Cursor, Pi, the OpenAI agents SDK, and custom YAML agents through one interface, so you can combine or swap them, supervise them, and govern them centrally.

Does omnigent work on Windows? Native Windows support is unresolved as of 2026-06; the practical path today is WSL2. On Linux it requires bubblewrap for sandboxing, and macOS uses the built-in seatbelt sandbox.

Is omnigent production-ready? No. It was created in June 2026 and is still labeled alpha, with open issues including a managed-sandbox auth bug under OIDC. Treat it as early and experiment before depending on it.

How do I stop agents from doing something risky? Use policies. They check every action and can pause for your approval, cap spend, or limit which tools an agent reaches, stacked at the server, agent, and session level.