Codex Patched
My Codex build with independent native modules, managed updates, and a fully remote build pipeline.
On this page
Codex Patched is my Codex build with native modules and separate version management. It lets me develop my own tools on top of upstream without rebuilding the large CLI for every compatible add-on change. A new action that core itself must perform still requires an explicit integration patch.
The main parts are separate: the modified Codex CLI, a small native host library, a manager, and feature libraries. The CLI loads the host through a validated boundary; the host pins a selected manager snapshot, and the manager invokes approved modules. This separation determines both the source architecture and which component needs rebuilding or an application restart.
Module capabilities
The source separates several areas:
| Module | Purpose |
|---|---|
| Runway | Context data, checkpoints, and assessment of the next work phase. |
| Session History | Bounded access to the session-history index. |
| Session State | State snapshots and restoration through host-owned operations. |
| Context Hooks | Hints at context and compaction boundaries. |
| Agent Policy | Checks agent launches against configured policy. |
| Model Route | Proposes a model route for host validation. |
| Approval Guard | Vetoes configured tool approvals at designated checkpoints. |
| Statusline | Displays configured indicators across multiple rows. |
| Tribe | Validates bounded task-transition and agent-count requests before calling the bound MCP connection. |
The Tribe module does not change durable state itself. It prepares a proposal; Codex must call the corresponding tool on the bound MCP connection and report that tool’s actual result. A missing connection does not turn a proposal into a successful operation.
FastCtx remains an external MCP connection for local files, search, and edits. Connecting it does not require a native library. A module’s presence in the source or build allowlist also does not mean a particular profile has selected it or the current process has loaded it.
Updates without rebuilding everything
A compatible feature change requires a new library for that module and reviewed activation. A compatible change to dispatch or feature selection requires a new manager library. The CLI and native host transport stay unchanged.
Changing the loader itself while retaining its interface requires a separate libcodex_native_host.so build. Codex loads it once per process, so the new version takes effect after a fresh launch. If authority, allowed effects, a core operation, or the integration interface changes, updating one .so is insufficient: the corresponding Codex integration must be changed and rebuilt.
Moving to another upstream prerelease is also a separate task. The project pins the source revision, checks the complete patch against a clean baseline, and does not treat an old binary as a new release merely because the package version changed.
Building entirely in the cloud
tools/build-codex-release submits the selected build to BuildBuddy Run. Source preparation is separate; starting Bazel, analyzing dependencies, compiling, and linking all happen on the cloud runner. Local Bazel with a remote cache does not substitute for a remote invocation here. If the cloud is unavailable, there is no automatic fallback to building on the workstation.
The current pipeline builds the modified CLI. The unchanged code mode host, exec server, and resources come from the exact official package associated with the pinned upstream revision. Archive provenance, its checksum, and individual file hashes are checked. Ready-made official components do not need recompilation just because my build changes.
The native host, manager, each add-on, and helper programs have separate build targets and artifact records. Selecting one module submits its corresponding target. The guide to heavy builds with Bazel and BuildBuddy explains this workflow in more detail.
A submitted job is not yet a finished distribution. First obtain a successful cloud result and the expected archive with its checksum, then download and verify the artifacts. The tools retain immutable build generations and their provenance. Claims about rebuild time or cache hits need a real execution log, not just inspection of the dependency graph.
Verification and activation
The codex modules command and the TUI’s /modules screen expose status, verification, version selection, disable, and rollback. Installing a library and choosing a profile’s active generation are separate operations. Packaging files does not automatically enable every available capability.
Package preparation checks records for the CLI and associated executables, native host, and selected libraries. Manifests bind them to their hashes; a set changed after verification must not silently enter the installation. Activation additionally checks the capability catalog and profile state, restoring the previous version selection on failure.
A running process can continue using a generation it has already pinned. A successful profile switch and actual loading of the new version are therefore verified separately. Installing a package does not automatically restart an active Codex process. Native modules remain trusted executable code: a matching hash confirms the bytes, but does not replace deciding whether to trust their implementation.