patch.moi/docs/pages/concepts/codex-fork-model.md

title	description
Codex fork model	The concrete Git topology patch.moi should learn from the neighboring Codex fork.

Codex Fork Model

The neighboring ../codex checkout is the concrete model for patch.moi concept development. It shows why patch.moi should treat Git as the project source of truth and keep Patch state focused on orchestration.

Observed Repository

Observed on 2026-05-16:

Fact	Value
Checkout	../codex
Current branch	code-mode-exec-hooks
Fork remote	origin -> https://github.com/peezy-tech/codex
Branch tracking	origin/code-mode-exec-hooks
Comparison branch	origin/main
Patch branch head	f8594cf39
Candidate tag at head	rust-v0.130.0
Local working tree	untracked codex-rs/code-mode/TYPECHECK_PLAN.md

There is no upstream remote configured in this checkout. That is an important setup case for patch.moi: the CLI or service should detect it and offer to add https://github.com/openai/codex.git as the upstream remote before running a release maintenance workflow.

Patch Stack

The maintained patch stack is the commits on code-mode-exec-hooks ahead of origin/main:

5e0d6c54e Expose Code Mode exec to hooks
d715d5829 Add native code mode replay action
a2fb3e6c9 Publish peezy codex npm packages
bc03f1afa Use fork-friendly Peezy npm release workflow
74e1540e1 Increase release build timeout
f8594cf39 Use peezy.tech npm scope

Those commits are the patch inventory. patch.moi should not duplicate them in a project file. It should read them from Git and record the runs that attempted to carry them forward.

What This Teaches patch.moi

The Codex fork makes the desired model concrete:

• origin/main is a useful local comparison baseline, but a real upstream remote is still needed for canonical release tags.
• code-mode-exec-hooks is the maintained patch branch, but internal use is not simply "run from this branch."
• rust-v0.130.0 at the branch head is a downstream candidate or release tag.
• the npm package rename to @peezy.tech/* is part of the patch stack, not a Patch service setting.
• the public release path is encoded in .github/workflows/rust-release.yml.
• the internal release surface should build the native binary, place it in the npm wrapper's local vendor layout, and use a Bun link workflow so the local codex command exercises the same JavaScript launcher path as a release.
• a dirty or untracked working tree should block automated rebases until the operator decides whether that local work belongs in the patch stack.

Maintenance Workspace

A patch application workspace for this repo should do the normal Git work:

cd ../codex
git status --short --branch
git remote get-url origin
git remote get-url upstream || git remote add upstream https://github.com/openai/codex.git
git fetch upstream --tags --prune
git fetch origin --prune
git rev-list --oneline origin/main..code-mode-exec-hooks

For an upstream release event, the workspace can resolve the upstream tag, rebase code-mode-exec-hooks, run Codex-specific checks, and push a candidate branch or tag when policy allows.

In service mode, that work should be triggered through the remote fork host. For example, patch.moi can create or update a maintenance branch on GitHub, trigger a runner, and let that runner perform the checkout, rebase, build, and push. The local ../codex checkout is a model for topology and local validation, not the service's durable execution surface.

Feature Workspace

Feature development should happen in a separate workspace or branch. A new custom feature starts from the current maintained branch, produces commits, and only becomes part of the maintained patch stack after it is intentionally merged or rebased into code-mode-exec-hooks.

Channel Split

The same candidate ref can serve different channels:

Channel	Codex fork example
Internal use	build the local native binary, stage it into the npm wrapper/vendor shape, and link that package with Bun
Public release	push rust-v* tags and let GitHub Actions publish @peezy.tech/* packages

Internal use should be close to the actual release surface without requiring the full multiplatform CI release. The useful local loop is:

cd ../codex
# Codex's Rust workspace lives under codex-rs.
(cd codex-rs && cargo build -p codex-cli --bin codex)
mkdir -p codex-cli/vendor/x86_64-unknown-linux-musl/codex
cp codex-rs/target/debug/codex codex-cli/vendor/x86_64-unknown-linux-musl/codex/codex
(cd codex-cli && bun link)
bun link @peezy.tech/codex
codex --version

This example shows the x64 Linux wrapper path. The exact target directory, target triple, and global-versus-project link choice can vary by host and validation target, but the principle is stable: test the npm wrapper plus native binary handoff locally, then leave multiplatform artifacts and trusted npm publishing to CI.