A control plane above the coding agents
Omnigent is for the point where choosing one AI coding tool stops being realistic. A team may use Claude Code for one repository, Codex for another, Cursor for interactive work, and a custom agent for research. Each normally brings its own session history, credentials, permissions, interface, and sub-agent behavior. Omnigent places a common system above them. Sessions can move between terminal, browser, phone, and a desktop shell; several harnesses can work together; teammates can join; and policies can inspect agent actions.
That “meta-harness” label is accurate. Omnigent does not replace the underlying agent. It starts, wraps, synchronizes, and governs Claude Code, Codex, Cursor, OpenCode, Hermes, Pi, and additional harnesses. Custom agents are YAML definitions containing a prompt, an executor, local Python functions, MCP servers, and sub-agents. A supervisor can delegate to different vendors, and each child can keep its own harness.
The included examples show the intended ceiling. Polly plans a coding task, sends work to agents in parallel Git worktrees, and routes each result to a reviewer from another vendor. Debby sends one question to Claude and GPT, presents both answers, and can run a critique round. A smaller research example searches the web through an MCP server and produces a sourced report. These are useful reference architectures, not just hello-world chatbots.
The strongest reason to use it is continuity
Omnigent’s best feature is that a session is no longer trapped in one terminal. Starting the CLI also launches a local web interface. A server deployment can make the same chat, terminal, files, and sub-agent activity reachable from a phone. Teammates can watch, contribute messages, co-attach to a live process on the host machine, or fork a conversation and continue independently.
The collaboration model is unusually direct, but it raises the stakes of permissions. Version 0.9.0 reverted an ownership restriction, so any shared editor can approve session actions rather than only the session owner. That may fit pairing, where every invited editor is trusted, but it is not a minor UI detail. Anyone who can approve can affect code and commands running on another machine. Share links and membership should be treated as operational access, not as passive screen sharing.
Deployment choices are broad. Docker Compose covers a normal server, with guides for several hosting services, Cloudflare, Databricks, and private access through Tailscale. Managed hosts can provision a cloud sandbox per session. Local agents can also run inside Modal, Daytona, E2B, Kubernetes, OpenShell, Boxlite, and other supported environments. This flexibility is valuable for platform teams, though each provider adds credentials, billing, networking, and its own failure modes.
Installation is a funnel, not the whole setup
The bootstrap script is impressively effective: install the package, detect existing model credentials, choose a default, and start a local session. Manual paths through uv, pip, Homebrew, or a source checkout are documented. The updater drains active sessions before replacing the installation, and uninstall can preserve history or explicitly purge it.
The dependency list explains why production is heavier. Omnigent requires Python 3.12, uv, and Git. Coding harnesses bring Node 22, npm, and pnpm. Native terminal wrappers require tmux, plus mandatory bubblewrap isolation on Linux; macOS uses its built-in sandbox. Windows supports the server, web UI, and SDK harnesses, but its native terminal wrappers are unavailable. Its Job Object contains a process tree without isolating the filesystem or network, so Windows is not an equivalent security target.
A self-hosted team deployment also needs authentication and runner design. Invite-only local accounts are available, along with OIDC for common identity providers and a proxy-header mode. Recent open reports say passkey authentication through self-hosted identity providers can hang in the Electron desktop shell, while the same login works in Chrome. Browser testing is essential before declaring an enterprise sign-in path ready.
Policies help, but missing telemetry can break them
Policies can allow, deny, or request approval for shell commands, file edits, token spending, and tool access. Rules stack at server, agent, and session levels. Built-ins include tool-call limits and dollar budgets. This is a meaningful advantage over supervising several independent CLIs by convention alone.
The enforcement surface is still maturing. Issue #4479 reports that Kimi harnesses do not provide model, token, or cost data. The missing values leave cost displays empty and cause budget policies to deny tool calls rather than enforce a usable allowance. An open storage issue is more operationally serious: one host accumulated 28 GB across 273 Codex-native session directories because crashed, orphaned, or undeleted sessions lacked global garbage collection. Busy hosts need disk monitoring and cleanup procedures now.
Multi-repository development has another concrete gap. Issue #2303 says a workspace containing several nested Git repositories breaks worktree handling and produces an empty Changes view because Omnigent expects the working root itself to be a repository. Teams with monorepos are fine; teams with a parent folder containing many separate services should split sessions or test the limitation carefully.
Anonymous usage telemetry is enabled by default. The README says it excludes sensitive and personally identifiable information, but regulated teams should review the dedicated telemetry documentation and set the opt-out deliberately.
Extraordinary pace, alpha expectations
The project was created in June 2026, had about 8,700 stars, and already showed 890 open issues and pull requests combined on August 12. Version 0.9.0 shipped on August 11, and the repository was pushed again the next day. Issues and fixes are moving within hours. This is exceptional momentum, but the alpha badge and pre-1.0 version describe the maturity more honestly than the feature count.
Use Omnigent when coordinating several agent runtimes has become harder than operating one shared layer. It can reduce vendor lock-in and make remote supervision practical. Do not mistake breadth for stability. Pin releases, isolate runners, monitor storage, test identity flows, and begin with repositories where an orchestration failure is recoverable.