Omnigent puts Claude Code, Codex and Cursor under one policy layer, and Linux needs bubblewrap

The installer is a piped shell script and uv is not optional

The documented default is one line that pipes a remote script into a shell:

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

Nothing in that command is pinned. It fetches the main branch rather than a tag, so the script you run can change without a release note attached to it, and the documented invocation carries no checksum and no signature. The prerequisites the installer checks for are uv and git, both required, and the package declares requires-python >=3.12, so Python 3.12 is the floor. Node.js 22 LTS or newer is a third requirement, with npm for the coding-harness CLIs installed by `omnigent run` and pnpm for the web UI, and pnpm is obtained either through `corepack enable` or `npm install -g pnpm`. For a reader deciding how to install, the practical difference is between a script you trust on sight and a package index you can pin, and both routes exist. The installer also volunteers to set up uv, tmux and bubblewrap when it finds them missing, which is convenient and is also how a missing tool gets installed without you naming it.

Extras are the switchboard, and two advertised sandboxes have no extra

Everything past the base install is a Python extra, and the same syntax works through the piped installer and through uv:

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

The catalog is grouped by role. Model providers are `databricks`, `bedrock`, and `vertex`. Sandbox providers are `modal`, `daytona`, `blaxel`, `boxlite`, `microsandbox`, `cwsandbox`, `e2b`, `openshell`, and `kubernetes`. SDK harnesses are `antigravity`, `copilot`, `cursor`, and `agents-sdk`. Storage and memory are `s3` and `hindsight`. Here is the wrinkle to settle before you plan a rollout: the headline list of sandbox targets names twelve providers, including Islo and Gensee, and neither appears in the extras list, while CoreWeave is advertised by name but installed as `cwsandbox`. A reader who maps advertised names onto extras by eye will conclude two of them cannot be installed at all. Verify that mapping yourself before a deployment plan depends on a particular sandbox.

On Linux a missing bwrap binary stops agent terminals from starting

The native `omnigent <harness>` wrappers, covering claude, codex, cursor, devin, hermes, kiro and pi, do not open a plain terminal. They wrap each agent terminal in a `bwrap` OS sandbox, and on Linux that isolation is mandatory, so a machine without the bubblewrap binary fails to start those terminals at all. macOS takes a different path: the wrappers use the built-in `seatbelt` sandbox and need nothing extra. `tmux` is required alongside it for the same wrappers. Optional CLIs plug into the same approval surface. Devin installs with `curl -fsSL https://cli.devin.ai/install.sh | bash` and signs in through `devin auth login`, and its tool approvals appear as Chat approval cards because the `PermissionRequest` hook is mirrored to the web UI, while remaining answerable in the embedded Terminal. Kiro follows the same shape, with one-time approvals also surfacing as Chat cards. What this means in practice is that Linux support has no fallback rung: the documented consequence of a missing `bwrap` is that those terminals fail to start, not that they run unconfined. A stripped container image that omits bubblewrap loses the native wrappers entirely.

Windows gets the package but not the bootstrap script

The README documents manual install routes alongside the one-line script, starting with uv or pip:

uv tool install omnigent        # or: pip install "omnigent"

That line is also the path for anyone who declines to pipe a remote script into a shell, and it accepts the same extras syntax:

uv tool install "omnigent[databricks,modal]"

The distribution tap remains the shortest option where it exists:

brew install omnigent-ai/tap/omnigent

For networks behind mirrors, the same tap can build from source with `HOMEBREW_PIP_INDEX_URL` and `HOMEBREW_CARGO_INDEX_URL` pointed at your own index, and both overrides are optional and do not affect prebuilt-bottle installs.

Tags say 0.16.0 while the manifest already reads 0.17.0.dev0

Version reporting is split across several files and they do not agree. The three most recent releases are v0.19.0 on 2026-10-20, v0.19.1 on 2026-10-21 and v0.20.0 on 2026-10-28, while pyproject.toml on the default branch declares version 0.22.0.dev0. The repository's last push is dated 2026-11-02, so main is already ahead of the newest tag. That gap is deliberate and it has teeth: the dependency list pins `omnigent-client==0.22.0.dev0` and `omnigent-ui-sdk==0.22.0.dev0`, because the three packages release together at one version and a published `omnigent==X` must resolve the SDK wheels built alongside it, with a workflow called release-omnigent.yml verifying that the pins match the tag. Local and editable installs skip that constraint by resolving through tool.uv.sources instead. The README also documents installing straight from the repository:

uv tool install -q --python 3.12 git+https://github.com/omnigent-ai/omnigent.git

The classifier still reads Development Status :: 3 - Alpha, so treat both paths as pre-1.0 and record which one you used.

Two dependency caps exist because upstream broke compatibility

Several pins in the dependency list are workarounds rather than preferences, and each one tells you what happens if you ignore it. `openai` is held to `>=1.0,<2.45` because openai-agents below 0.18.2 omits a field that openai 2.45 and above requires, and the accompanying comment says to keep the cap until the websockets pin can be lifted. `rich` is held to `>=14,<16` because the e2b extra pulls an SDK at or above 2.26 that needs rich 14 or newer. `websockets` is held below 15 because the asyncio client at 15 and above hangs on macOS before emitting any handshake bytes, tracked as issue #1514. The consequence for an operator is that Omnigent will not accept the current generation of these libraries, and if your environment needs openai or websockets outside those ranges you will resolve the conflict yourself. A related safeguard lives in the build: setup.py writes `omnigent/_build_info.py` during the wheel build so the update check in `omnigent/update_check.py` can report a stale build without shelling out to git or contacting a remote endpoint at startup.

Policies bind to the whole server, one agent, or one chat

Governance is the least mechanical part of the design and the most consequential. A policy can pause for your approval before a risky action runs, cap spend, or limit which tools an agent is allowed to reach, and it can apply to the whole server, one agent, or a single chat. Three scopes in one system is what makes shared deployments workable, since a strict policy can sit on a team server while a permissive one covers a private scratch conversation.

Contributing needs Rust, pnpm and four agent instruction files

The contributor side is heavier than the one-line install suggests. The justfile drives everything, and its setup group runs `uv sync --extra all --group dev` for the Python environment, a Ruby bundle check inside `web/ios`, and a presence check for `omnidev`, a Rust tool it installs from source with `cargo install --path dev/omnidev --locked --force`. A Python project therefore needs a Rust toolchain for its own dev command: `just dev` runs `omnidev`, and `just dev-mobile` adds `--vite-host 0.0.0.0 --trust-lan-origins` to bind the Vite server to the LAN. Ruby and iOS tooling arrive for `web/ios`, where the simulator can be overridden with `OMNIGENT_IOS_SIMULATOR`, otherwise an available iPhone is used, preferring a booted one. Local database work is docker-based, with `crdb-up` starting a CockroachDB compose file and waiting with a ninety-second timeout. At the top level the repository also carries `.claude/`, `AGENTS.md`, `CLAUDE.md`, `CONTRIBUTING.md`, `SECURITY.md`, a DCO file, `railway.toml`, `render.yaml`, `openapi.json` and an `examples/` tree that includes deep-research, extensions, sentinel and an aws_analyst directory. That layout is the reason to read those files before your first patch rather than after your first rejected one.

Editorial conclusion

Omnigent suits a team that runs more than one coding agent at once and needs one policy surface across them, on macOS or Linux with uv already present. Do not assume a sandbox provider is installable just because its name appears in the headline list. Before adopting, pin a tag rather than the main branch, read the extras catalog against the providers you need, and budget for the mandatory bubblewrap dependency on Linux.

Frequently asked questions

Official sources

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