our codex fork as a standalone system

It is tempting to describe the Netsky Codex fork as “the Codex dependency.” That description is too small for what the code actually exposes.

The better model is this: the Netsky Codex fork is already a small standalone system with its own install path, patch policy, channel contract, and reusable thread runtime. Netsky is an orchestrator built on top of that substrate, not the place where those capabilities first appear. The most useful primary artifacts are the fork’s own FORK.md, the Codex Rust CLI README, the channel docs, and the small netsky-codex wrapper.

That is also why this post needs to sit beside, not inside, how Netsky leverages the Codex fork. That companion post is about the boundary from Netsky’s side. This one is about the fork itself as a reusable runtime surface. Earlier posts such as Codex CLI joins the constellation and iMessage for Codex CLI (and Claude Code) covered integration moments; this post is about the fork-owned substrate they depended on.

flowchart LR
    producer[external producer]
    wrapper[netsky-codex wrapper]

    subgraph fork[Codex fork]
        channel[channel inbox/outbox]
        cli[codex / exec / mcp-server]
        runtime[Config + ThreadManager + Codex thread]
    end

    producer --> channel
    cli --> runtime
    channel --> runtime
    runtime --> channel
    wrapper --> runtime

why this is more than a dependency #

The fastest way to see the distinction is to ask what still exists if you mentally subtract Netsky.

Quite a lot does. The Rust Codex CLI already exposes several reusable surfaces before Netsky ever touches it.

Those surfaces are documented in the fork’s own README, not invented in Netsky code.

why the fork exists #

The fork exists because the standalone Codex surface needed one capability Netsky could not fake cleanly from the outside: channels.

The channel docs describe the shape directly. Codex can accept turns from an external process and emit terminal outcomes back to that process. The current implementation is filesystem-backed, but the envelope shape and delivery rules are intentionally transport-neutral enough to support MCP and other sources on the same contract.

That matters even outside Netsky. A channel is a general way to drive a Codex session without typing into the terminal by hand. iMessage for Codex CLI (and Claude Code) is one concrete example of why that matters, but the contract itself is broader than any one transport.

{
  "from": "driver",
  "kind": "brief",
  "text": "Say hello in one sentence.",
  "ts": "2026-04-17T16:00:00Z"
}

what makes it a fork #

The repository says the quiet part out loud. This is the Netsky fork of openai/codex, and FORK.md documents the patch set and why it exists.

That patch stack comes straight from FORK.md.

That is already more than “we changed a flag.” It is a maintained runtime branch with a defined patch stack.

the standalone surfaces #

The fork-local install path is also explicit. FORK.md documents one rebuild ritual, one install script, and one reason not to install from a stock upstream checkout when the local build path needs the fork-specific feature gating. The root README points fork-local source installs back to FORK.md so the source tree describes itself honestly.

scripts/install-codex-fork.sh
codex --version

the runtime under the wrapper #

The smallest proof that this is a standalone system is the wrapper Netsky uses. The wrapper is useful evidence precisely because it is so thin.

The netsky-codex wrapper does not implement a new model loop. It configures and drives the fork’s existing runtime pieces: Config, init_state_db, AuthManager, ExecServerRuntimePaths, EnvironmentManager, thread_store_from_config, and ThreadManager. Starting a session means building that runtime once, then asking it to start a thread with a cwd and an initial prompt.

After that, the wrapper surface is tiny. ForkCodexSession exposes a thread_id, a submit(...) method for new user input, and a subscription stream of summarized Codex events. Underneath, the thread loop is still the fork’s thread model: Op::UserInput in, EventMsg out.

That is not what “tool wrapper” code looks like. It is what “consumer of a reusable runtime” code looks like.

the channel contract is a system contract #

The channel feature is also broader than a Netsky-only bus.

The docs define the inbox, outbox, and processed directories. They define the envelope fields, filename rules, delivery semantics, receipts, terminal outcomes, and MCP-notification interop. They also point to a demo script and a dedicated roundtrip test in the fork tree.

That is a real system boundary. A producer does not need to know anything about Netsky to speak that protocol. Netsky just happens to be one strong consumer of it.

how this differs from “Codex as a tool inside Netsky” #

Treating Codex as only a tool inside Netsky gets the layering backwards.

If Codex were just a tool, Netsky would be the place that invented the runtime loop, the stateful thread boundary, the event stream, and the channel contract. That is not what the code shows.

The fork already has:

• a standalone CLI and exec surface
• a documented external channel contract
• a reusable thread manager and thread lifecycle
• its own auth, config, environment, and sandbox setup
• a maintained fork policy and rebuild path

What Netsky adds is orchestration on top: actor identity, task ownership, durable routing, restart policy, notes, logs, and web views. The fork does not disappear inside that stack. It remains the execution substrate underneath it.

That is the better mental model going forward. Netsky is not hiding a mystery binary under the hood. It is standing on a fork that already behaves like a small local system in its own right, with enough structure that another consumer could reuse the same surfaces without inheriting the rest of Netsky.