126 lines
4.9 KiB
Markdown
126 lines
4.9 KiB
Markdown
---
|
|
title: Codex fork model
|
|
description: 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`:
|
|
|
|
```text
|
|
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:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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.
|