Omnigent: Databricks' Meta-Harness for Orchestrating Claude Code, Codex, and Custom Agents

If you run more than one coding agent, you have probably noticed the same thing: each one is its own island. Claude Code has its sessions, permissions, and skills. Codex has a separate set. Switching between them means switching mental models, re-explaining context, and re-configuring guardrails in each tool. There is no shared layer that travels with you.

On June 16, 2026, Databricks open-sourced Omnigent, an Apache-2.0 project it calls a "meta-harness." The pitch in the launch announcement is direct: instead of replacing the agent harnesses you already use, Omnigent sits one level above them and makes them interoperable. This post covers what that actually means, the three things it does, how to install it, and whether it earns a place in your stack.

Last updated: June 17, 2026

What a "Meta-Harness" Actually Means

A harness is the runtime around a model: the loop that feeds it tools, manages context, enforces permissions, and renders output. Claude Code is a harness. Codex is a harness. Each one is, in Databricks' words, "its own silo, with its own context, its own controls."

A meta-harness is a layer above those silos. Omnigent's framing is that it "lifts your work above any single harness, so your sessions, policies, and skills stay with you" rather than living inside one CLI. Practically, that means you start a session through Omnigent, and Omnigent decides which underlying harness and model actually runs the work. You can swap the harness underneath without rewriting the agent definition.

That is the whole bet: the orchestration, the guardrails, and the session state belong to you, not to whichever vendor's CLI you happened to open.

The Three Things Omnigent Does

The announcement organizes the project around three capabilities.

1. Composition

Omnigent lets you "combine multiple models, harnesses, and techniques without rewriting code." The supported harnesses today are Claude Code (claude-sdk), Codex, Pi, OpenAI Agents, and Open Responses, selectable per run with a --harness flag. You can point the same agent definition at a different model with --model, so a single YAML file can run on Claude one day and a Codex model the next.

This is the part most useful to people who already maintain prompts and tool definitions for one agent and do not want to fork them for another.

2. Control

Omnigent enforces "stateful, contextual policies" at the meta-harness layer: cost budgets, permissions, and other guardrails that apply regardless of which underlying harness runs. The argument is that a guardrail you set in Claude Code does not follow you into Codex, but a guardrail set in Omnigent applies to both because it lives above them.

3. Collaboration

You can "share live agent sessions via URL," letting a teammate watch a running agent and steer it in real time. This is the feature most clearly aimed at teams rather than solo developers, and it leans on Omnigent's server mode, which exposes a web UI on http://localhost:6767 by default.

Installing It

Omnigent is a Python CLI distributed on PyPI, with a Homebrew tap and an install script. The quickstart lists the prerequisites:

• Python 3.12 or newer
• uv (recommended) or pip
• Node.js 22 LTS or newer with npm (needed for the Claude Code, Codex, and Pi harnesses, which are Node-based CLIs)
• tmux (used by the native harness wrappers)
• On Linux only, bubblewrap (bwrap) for sandboxing

The cleanest install path is uv, which isolates the tool from your system Python:

uv tool install omnigent

Other supported routes from the README:

# Homebrew
brew install omnigent-ai/tap/omnigent

# pip
pip install omnigent

# one-line installer
curl -fsSL https://omnigent.ai/install.sh | sh

Verify the install:

omnigent --version

At the time of writing this returns omnigent 0.1.1. The project is explicitly in alpha, so expect rough edges and frequent updates (omnigent upgrade pulls the latest release).

Connecting Your Existing Agents

The setup step worth understanding is how Omnigent gets credentials. Running the wizard:

omnigent setup

detects credentials already present on your machine. If you have the claude and codex CLIs installed and authenticated, Omnigent picks them up as subscription-backed harnesses, meaning it rides your existing Claude Pro/Max and ChatGPT logins rather than requiring separate API keys. You can confirm what it found:

omnigent config list

A machine with both CLIs logged in and a local Ollama install shows each harness with its detected credential source: subscription via the claude CLI, subscription via the codex CLI, and a local Ollama base URL for Pi and Codex. For raw API access instead, the setup flow also accepts Anthropic, OpenAI, and gateway keys (OpenRouter, Azure, LiteLLM, vLLM), plus Databricks workspaces if you install the omnigent[databricks] extra.

Running Something

The fastest way to see orchestration work is one of the two bundled example agents.

debby is a two-headed brainstorming agent that "sends every question to both Claude and GPT and lets them debate," which is a clean demonstration of composition across two vendors in a single session:

omnigent debby

polly is the bundled multi-agent coding orchestrator, and it is what a bare omnigent launches when a Claude credential is configured:

omnigent polly
# or non-interactively:
omnigent polly -p "review the last commit"

You can also launch a harness directly, skipping the orchestrator:

omnigent claude                       # Claude Code in an Omnigent terminal
omnigent codex                        # Codex TUI in an Omnigent terminal
omnigent run --harness codex -p "explain this repo"

Custom agents are YAML files declaring a prompt, tools, and optional sub-agents, run with omnigent run path/to/agent.yaml. The full schema is in the Agent YAML spec. For the collaboration features, omnigent server start runs a background server and omnigent host registers your machine, after which the web UI at http://localhost:6767 is the shared surface.

Where It Fits, and Where It Does Not

Omnigent is interesting precisely because it does not compete with Claude Code or Codex. It wraps them. That makes the decision about adopting it different from the usual tool-versus-tool comparison.

It is a reasonable fit if you genuinely run multiple harnesses and feel the pain of duplicated config, or if you are on a team that wants shared session visibility and centralized cost and permission policy. The composition story is real: one agent definition that can target different models and harnesses is a maintenance win once you are past a single tool.

It is harder to justify if you live entirely inside one harness. If Claude Code is your whole world, a meta-harness adds a layer, a server process, and a tmux dependency to abstract over a problem you do not have yet. There is also the alpha caveat: at version 0.1.1 with an Apache-2.0 license and an active Discord, this is early software backed by a vendor (Databricks) whose own agent platform it conveniently plugs into.

The honest read: Omnigent is betting that the durable thing in agentic development is not any single harness but the orchestration, policy, and session layer that spans them. That is a credible bet as more teams run more than one agent. Whether the abstraction is worth the extra moving parts depends entirely on how many islands you are currently maintaining by hand. If the answer is one, wait. If it is three, this is worth an afternoon.

Sources

• Introducing Omnigent (Databricks blog)
• omnigent-ai/omnigent on GitHub
• Omnigent install quickstart
• Agent YAML spec