Overview

apply-patch-go

A faithful Go port of the apply_patch primitive that OpenAI Codex uses to edit files, verified one-to-one against the upstream Rust crate's own test corpus, so an agent's patches behave identically. I built it for a Codex-style MCP server, then used it to prove something: that a well-tested library can be ported to another language fully autonomously by a team of agents, with me out of the loop.

GoCLI
Coding AgentsAutonomous AgentsDeveloper Tools
View GitHub
apply-patch-go

Coding agents don’t really “edit files”; they emit patches, and something on the other side has to apply them safely. OpenAI Codex has a particularly good patch primitive for this, apply_patch: a forgiving format with a fuzzy-context matcher that survives small drift between what the model thinks a file says and what it actually says. GPT models are trained inside the Codex harness, so they’re fluent in exactly these tools (apply_patch, exec_command, write_stdin) and they expect them to behave a very specific way.

That’s why I needed this. I was building Zodex, a remote MCP server that hands ChatGPT-class agents a real VPS to do coding on. For those Codex-trained models to feel at home, Zodex’s apply_patch had to match the original’s behavior exactly, not approximately. With agent file-editing, “close enough” is a trap: a subtle difference in whitespace handling or partial-success semantics means a model produces patches that almost apply, and you get silent, maddening failures. So I set out to reproduce the Codex crate’s observable behavior one-to-one in Go. (I started Zodex in Go too, later decided Rust suited it better and switched, but I kept this port alive, both for the experiment below and because so much of my agent and DevOps tooling is Go.)

Parity, not resemblance

I held the port to matching the upstream crate at every layer an agent or script could observe:

  • patch parsing, including the fuzzy line-matching that lets context lines match even when whitespace has drifted
  • patch application: add, delete, update, move, overwrite, trailing-newline handling, and partial-success semantics
  • CLI behavior and exact stdout/stderr, since agents read those streams
  • verified-invocation parsing, including shell/heredoc extraction across bash, sh, zsh, powershell, pwsh, and cmd, because Codex invokes the tool through a shell, so faithfully parsing those calls means replicating how each shell unwraps a heredoc
  • unified-diff generation and the exported public API surface

The real experiment: porting it with zero humans in the loop

Here’s the part I actually cared about. I didn’t want to hand-port this crate. I wanted to find out whether I could design an agentic workflow that ports an entire Rust library to Go fully autonomously, with no human intervention after the initial setup. apply_patch was the perfect test case, because the upstream crate is exceptionally well-tested: 150+ tests that pin down behavior without assuming anything about the internals. A test suite like that is a flawless oracle, and an oracle is all an agent loop really needs.

So instead of prompting “port this to Go,” I designed a verification loop, much like the Agentic Refactoring workflow:

  1. Start from red. I brought the upstream tests over first and proved they all failed against an empty Go implementation.
  2. Dispatch a worker. A lead agent sends a worker agent with a fresh context window to push coverage as far as it can: implement, run tests, commit, and write down exactly how far it got in a porting-status document.
  3. Hand off and repeat. The lead reads that status, then sends the next worker with a clean context to pick up where the last left off. Fresh context every round is what kept quality from degrading.
  4. Loop until green. Over a few hours, worker after worker drove the suite toward 100% passing; then a final pass cleaned up the codebase.

I never touched the implementation after designing the loop. It was the first time I’d built a system that could autonomously port a complex piece of code end to end, and the lesson stuck with me: if code is well-tested, its tests are the lever. Point a disciplined agent loop at them and the implementation builds itself. The porting-status doc the agents kept updating is still in the repo, a little trace of the loop running on its own.

Two ways to use it

The result ships as a standalone apply_patch CLI (go install …) that reads a patch from an argument or stdin, and as a small Go library (ApplyPatch(patch, &stdout, &stderr)) so the exact same semantics can be embedded directly in a Go agent harness. One statically-linked binary, no runtime, Apache-2.0, and a Rust-parity harness that can diff it head-to-head against a compiled upstream apply_patch binary, just to keep it honest.

Use ← and → to navigate