Bernstein vs OpenAI Codex: quick decision guide

Install both

npm i -g @openai/codex  (or brew install --cask codex)

pipx install bernstein

Feature matrix

Adapter source: src/bernstein/adapters/codex.py | Upstream homepage: github.com

Verifiable facts

The brief for this surface requires at least three facts that a reader can verify against a primary source. The list below is built from the bernstein adapter source and, when available, the upstream project's own pages.

1. Bernstein ships a OpenAI Codex adapter at src/bernstein/adapters/codex.py that wraps the upstream CLI as one of 42 routable agents. [source: bernstein adapter source, as of 2026-10-01]
2. Upstream install command, as recorded in the bernstein adapter, is "npm i -g @openai/codex (or brew install --cask codex)". [source: upstream docs, as of 2026-10-01]
3. Bernstein last verified its adapter against upstream @openai/codex 0.117.x on 2026-05-05. [source: bernstein adapter source, as of 2026-05-05]
4. OpenAI Codex is flagged parallel-safe in Bernstein's adapter contract, meaning multiple instances can run in separate git worktrees against the same goal. [source: bernstein adapter source, as of 2026-10-01]
5. OpenAI Codex supports the Model Context Protocol per the bernstein adapter contract, so Bernstein can inject MCP servers into its session. [source: bernstein adapter source, as of 2026-10-01]
6. OpenAI Codex is distributed under OpenAI proprietary, per the operator-curated overlay in data/adapters-overlay.json. [source: upstream docs, as of 2026-10-01]

Where OpenAI Codex fits in Bernstein

Bernstein registers OpenAI Codex under the slug "codex" and the registry name "codex". The adapter source lives at src/bernstein/adapters/codex.py in the bernstein repo and was last touched at build time 2026-10-01. The OpenAI Codex adapter file is 596 lines and 27,163 bytes long, fingerprinted 42334cd3fd5e0843 (first 16 hex chars of SHA-256). Operators install OpenAI Codex on a worker box with "npm i -g @openai/codex (or brew install --cask codex)" before Bernstein routes any task to it. No upstream GitHub repository is recorded in the bernstein adapter for OpenAI Codex; refer to the upstream vendor's documentation when auditing. The OpenAI Codex project's homepage at github.com is the primary source for upstream release notes. Bernstein last verified the OpenAI Codex adapter against upstream @openai/codex 0.117.x on 2026-05-05, recorded inline in the adapter source. OpenAI Codex accepts MCP servers, so Bernstein injects the same MCP toolset it provides every other MCP-aware adapter. OpenAI Codex is flagged parallel-safe, meaning multiple Bernstein workers can spawn it in separate git worktrees against the same goal without file collisions. OpenAI Codex ships under OpenAI proprietary per the operator-curated overlay; cross-check against the upstream LICENSE file before production use. Auth model for OpenAI Codex is "OPENAI_API_KEY", scoped per adapter so a leaked key never grants access to a different model family. Bernstein routes tasks to OpenAI Codex when its pass rate on similar work clears the configured threshold, otherwise the deterministic Python scheduler picks a different adapter from the 40+ adapter catalog.

Adapter source excerpt

The module docstring of the OpenAI Codex adapter, as it stands in the bernstein repo. Punctuation is normalised for the web; the wording is the author's. Length: 3343 characters.

OpenAI Codex CLI adapter. Last verified against upstream @openai/codex 0.152.1 on 2026-09-02. Install: ``npm i -g @openai/codex`` (or ``brew install --cask codex``). .. important:: **codex >= 0.152 speaks only the Responses API.** ``wire_api = "chat"`` in a custom provider block is a hard startup error, not a fallback:: Error loading config.toml: `wire_api = "chat"` is no longer supported. How to fix: set `wire_api = "responses"` in your provider config. This adapter allow-lists ``OPENAI_BASE_URL``, which advertises support for custom OpenAI-compatible endpoints. That support is narrower than it looks: an endpoint serving only ``/v1/chat/completions`` **cannot drive codex at all**, however compatible it is otherwise. Point ``OPENAI_BASE_URL`` at a deployment that implements ``/v1/responses`` (issue #5314). Recommended models: ``gpt-5.5`` (GA 2026-04-24), which is also the pinned fallback, or ``gpt-5.4-mini`` for cheap work. ``gpt-5.4`` is no longer served on the ChatGPT-account auth path. The o-series reasoning models (``o3``, ``o4-mini``) are also accepted by the CLI. Sandbox posture is derived from the adapter's declared :class:`~bernstein.adapters._contract.DangerousModeStrategy` rather than hardcoded, because the right answer depends on where the CLI runs. ``codex exec --sandbox workspace-write`` is implemented with bubblewrap on Linux, and bubblewrap needs an unprivileged user namespace to start. A runner that already provides isolation typically denies exactly that: a container started with ``--cap-drop ALL --security-opt no-new-privileges:true``, or a host with unprivileged user namespaces disabled, makes every model-issued shell command fail with ``bwrap: No permissions to create a new namespace``. The failure is silent from the orchestrator's side -- ``codex exec`` still emits ``turn.completed`` and exits 0 after producing an empty diff -- so the run reads as a model that had nothing to do rather than as a sandbox that could not initialise. An operator whose runner is already isolated therefore declares the escalated strategy, and the spawn passes ``--dangerously-bypass-approvals-and-sandbox`` instead. Upstream's own help text scopes that flag the same way: "Intended solely for running in environments that are externally sandboxed." The un-escalated default stays ``--sandbox workspace-write``, so a spawn on a plain host keeps the vendor sandbox. The escalated strategy is a blunt instrument, though: it means "no permission surface exists to skip" and says nothing about *why* skipping is safe. The narrower route is the host-isolation declaration (issue #5341). An operator running inside a container or VM they control states the isolation tier the host applies and the evidence for it -- ``host_isolation_tier`` and ``host_isolation_evidence``, resolved through the normal config precedence chain -- and the spawner injects it into this adapter, which advertises that it consumes one via :attr:`CodexAdapter.consumes_host_isolation`. A declared ``container`` or ``vm`` tier is a boundary that replaces what bubblewrap would have supplied, so the vendor sandbox is dropped; ``process`` and ``none`` are not, so it stays. The declaration is written to the HMAC audit chain at the dispatch seam, which is what makes it an operator statement on the record rather than an unexplained flag flip.

Adapter telemetry

When to pick which

FAQ