Codex should remain the coding harness
Teams adopt Codex because it already understands the shape of software work. It can inspect a repository, follow project instructions, use skills, propose patches, run local tools, and work inside explicit approval and sandbox boundaries. Replacing that harness just to add centralized model governance would create a second operating model for engineers to learn.
Punk takes a narrower approach. The `punk launch codex` command keeps Codex in charge of the terminal or desktop experience while directing its model requests through Punk’s governed Responses runtime. This is a model-provider integration, not an MCP integration and not a remote tool runner.
That boundary matters. Codex continues to own repository access and local execution. Punk owns model routing, policy and data-loss-prevention checks, tracing, cost accounting, route explanations, and evidence-gated optimization. Each system stays responsible for the layer it can control and verify.
What an AI gateway adds to Codex
A direct coding-agent session can be productive, but platform teams still need operational answers across many engineers and repositories:
- Which model and provider served a step?
- What did the step cost?
- Did policy or a sensitive-data rule affect the route?
- Was a tool call proposed, and with which bounded arguments?
- Did the runtime use a live model, a qualified reusable route, or a fallback?
- Can an operator inspect the evidence after the session?
Punk records those decisions as part of the same trace ledger used by other agent applications. Every served step receives a run identifier and route explanation. A team can inspect provider selection, policy results, proposed tool calls, token and cost accounting, and whether a cache or artifact route was eligible.
This does not make every coding step reusable. Coding work often depends on changing repository state, new test output, and fresh instructions. Punk’s job is to observe that context, keep unsafe or unsupported work on a live path, and let any future optimization earn its place through evidence.
The launcher protects the provider boundary
The launcher creates a separate, versioned Codex home instead of editing the engineer’s normal configuration. It writes a Punk provider configuration and compatible model catalog without persisting the API credential. On supported systems, those managed files use owner-only permissions and atomic replacement.
The isolated home also gives the integration a clean rollback: quit the Punk-launched process and start Codex normally. Existing personal Codex state remains where it was.
For Codex CLI, Punk applies the managed model, provider, endpoint, credential variable, catalog, and attribution settings at the highest supported precedence. It rejects pass-through provider overrides that could silently bypass the governed route. Other Codex arguments continue through unchanged.
On macOS, the desktop path uses a guarded fresh process. Punk verifies the application identity, checks that another Codex Desktop process is not already running, and fails closed if project configuration could override the managed provider. That is less convenient than reusing an arbitrary open process, but it is the only honest way to know the new process inherited the intended environment.
Tool execution still belongs to Codex
Coding agents need powerful local tools. Central governance should not blur who executes them.
When a model proposes a function call or a custom call such as apply_patch, Punk can evaluate the proposed action and its arguments before returning the typed call. Codex then applies its own local approval and sandbox rules. Only Codex executes the tool, and a later model request carries the result back through Punk.
This layered decision is useful for enterprise Codex deployments. Punk can enforce organization-wide policy on the model path while Codex preserves workstation-level controls close to the repository and operating system. Neither layer is presented as a substitute for the other.
Punk never adds a flag that bypasses Codex approvals or sandboxing. If an operator explicitly changes those Codex controls, that remains a visible local choice rather than hidden gateway behavior.
Compatibility needs evidence, not assumptions
Agent protocols change. A launcher that happened to work once can drift as the upstream client evolves.
Punk maintains versioned compatibility fixtures for buffered and streamed Responses traffic, function tools, custom tools, parallel calls, reasoning summaries, and text input. The launcher includes a doctor that checks the installed Codex version, the declared transport capabilities, the gateway health contract, the Responses endpoint, and the managed home before a real session starts.
Punk also keeps a bounded, privacy-safe launcher event log inside the isolated home. It records launch and compatibility outcomes without storing prompts, arguments, credentials, paths, request bodies, or provider errors. This helps a platform team distinguish “Codex could not start” from “the gateway rejected a model step” without creating a second sensitive transcript.
A practical rollout for platform teams
Start with a small engineering group and an observe-oriented policy. Run the launcher doctor, send one non-destructive Codex task, and confirm that the session appears in Punk with the expected app, agent, and subject identity. Review the route explanation, cost, and proposed tools before expanding access.
Then test the failure paths: an unsupported client version, an unreachable gateway, a conflicting desktop process, and a project-level provider override. A governed Codex integration is credible when those cases fail clearly—not only when the happy path produces code.
The goal is not to put another interface in front of engineers. It is to keep Codex as the familiar harness while giving the organization a controlled, inspectable runtime underneath it.
Questions readers ask
Does Punk replace Codex or execute Codex tools?
No. Codex remains the coding-agent harness and executes tools locally under its own approval and sandbox rules. Punk governs model traffic and returns typed tool proposals; it does not run Codex’s shell or patch tools.
Can Punk launch both Codex CLI and Codex Desktop?
Punk supports Codex CLI on macOS, Linux, and Windows. It also supports a guarded fresh-process launch of Codex Desktop on macOS. Desktop launch on Linux and Windows is not currently supported.
Does the Codex launcher modify the normal Codex configuration?
No. Punk creates a separate versioned CODEX_HOME, writes only marked managed files there, and leaves the user’s normal Codex home and repository configuration untouched.