CrossPatch

CrossPatch turns incident evidence into agent-proposed fixes that must survive adversarial review and human approval before a hash-bound warrant permits execution.

Comment

Inspiration

Most autonomous coding-agent demos follow the same pattern: the agent finds a bug, edits the code, runs its own tests and announces success. That is impressive, but it left me with a harder question:

Should the same model be allowed to investigate a failure, propose a repair, execute it and decide that its own work passed?

For an SRE or platform team, a plausible patch is not enough. They need trustworthy evidence, separation of responsibilities, explicit human authority, deterministic execution and proof that can be inspected afterwards.

So, I built CrossPatch to explore that missing layer. It lets AI reason deeply about an incident without giving the AI direct control over the worktree, shell, tests or final execution decision.

What it does

CrossPatch is a failure-first SRE incident room and a due-process layer for agent-proposed fixes.

It turns a reproduced reliability incident into a controlled sequence:

  1. Evidence is collected and sanitized. Raw logs and traces are treated as untrusted. Models receive only tagged, sanitized projections.
  2. Five GPT-5.6 specialists review the incident.
    • Prosecutor — GPT-5.6 Luna: challenges the leading explanation with rival hypotheses and negative controls.
    • Inspector — GPT-5.6 Terra: reconstructs the failure mechanism from cited evidence.
    • Counsel — GPT-5.6 Terra: proposes and defends the smallest viable patch.
    • Magistrate — GPT-5.6 Sol: returns only 'CLEAR', 'REMAND', 'BLOCK', or 'ABSTAIN'.
    • Bailiff — GPT-5.6 Luna: can call only 'execute_warrant(id)' after human approval.
  3. A 'REMAND' rejects weak work and forces a materially different revision at a higher reasoning level.
  4. A 'CLEAR' verdict creates a proposed warrant - not execution authority.
  5. A human reviews and approves the exact hash-bound warrant.
  6. Trusted software creates the disposable worktree, applies the reviewed patch, runs an immutable test plan and independently observes the result.
  7. CrossPatch retains the evidence, verdicts, warrant, patch hash, test receipt, timeline and signature as a verifiable case file.

The five personas are AI agents powered by GPT-5.6; portraits generated with ChatGPT Images; any resemblance to any real persons is purely coincidental.

The models never write files, choose shell commands, run tests or declare that a test passed. Those responsibilities belong to deterministic software outside the model boundary.

CrossPatch currently ships two genuine webhook reliability scenarios:

  • A concurrency race that creates duplicate jobs and deliveries.
  • A payload-equivalence defect that rejects a correctly signed retry merely because its JSON formatting or key order changed.

Both scenarios run against CrossPatch’s own deliberately flawed sandbox victim service; no third-party system or infrastructure is targeted.

No failures, model outputs or successful results are seeded for the demo.

You can explore the live product at CrossPatch, browse its published production cases or replay and inspect a genuine signed end-to-end readiness case locally without an OpenAI key:

git clone https://github.com/asadvendor-boop/CrossPatch.git
cd CrossPatch
make replay

How I built it

CrossPatch uses the OpenAI Agents SDK with the Responses API. The runtime combines per-agent model settings and reasoning policies with structured outputs, SDK sessions and tracing, narrowly scoped guardrails and bounded handoffs.

The three MCP surfaces have deliberately different authority:

  • Evidence MCP is private, incident-scoped, sanitized and read-only.
  • Broker MCP is private and exposes only 'execute_warrant(id)' to the Bailiff.
  • Judge MCP exposes read-only projections of explicitly published cases. It cannot approve, mutate, run tests, access raw evidence or retrieve secrets.

The backend is built with Python, FastAPI, PostgreSQL, SQLAlchemy and the OpenAI Agents SDK. The incident-room interface uses Next.js, React and TypeScript. Docker Compose runs the complete local topology, with Caddy as the only service publishing host ports.

The mutation broker binds approval to the incident, base Git SHA, exact patch bytes, allowed paths, immutable test plan, verdict, evidence head, runner and environment digests, expiry, approver and single-use nonce. Changing any bound value invalidates the warrant before a worktree or process is created.

Candidate code runs with a read-only workspace, no control-plane secrets and no authority to create its own receipt. A trusted external PostgreSQL and HTTP observer - not the candidate process or its exit code - decides whether the repair passed.

I used Codex throughout the project, not only for initial scaffolding. I made the product, safety, interface and approval decisions; Codex helped translate those decisions into architecture, test-first implementation, security reviews, browser testing, deployment automation and reproducible evidence. When reviews uncovered gaps, such as candidate output being mistaken for trusted proof or the UI failing to recognize a real pending warrant, those findings became regression tests before they were fixed!

GPT-5.6 is therefore used in two distinct ways: First, it is used as the reasoning layer inside the five CrossPatch specialists and secondly it was used through Codex as the implementation and review collaborator that helped build the surrounding deterministic system.

Challenges I ran into

The hardest challenge was defining what human approval actually means. A simple "Approve" button is not a security boundary if the patch, paths, commands or test plan can change afterward. This led to the hash-bound, single-use warrant design.

Another challenge was prompt injection hidden inside operational evidence. A correctly signed webhook can still carry instruction-like text into an operational log. CrossPatch preserves raw bytes only in its artifact store, removes or tags instruction-like content before model context and continues treating the sanitized result as untrusted.

I also learned that candidate-controlled execution cannot be trusted to grade itself. A zero exit code, candidate-written file or candidate-generated receipt is not proof. The final design uses a separate trusted observer that derives success from external HTTP and PostgreSQL state and rechecks immutable hashes after execution.

Reproducing the webhook race honestly was difficult too. The affected service had to produce the real '1 / 2 / 2' database outcome, while the repaired candidate had to reach '1 / 1 / 1', without sleeps, mutable fixtures, forced failures or hand-authored evidence.

Finally, making all of these controls understandable in a short demo required treating design as part of the safety system. The incident room shows the specialist conversation, evidence, 'REMAND', human gate, exact warrant and trusted receipt as one visible sequence.

Accomplishments that I am proud of

CrossPatch is a working, monitored deployment - not a prerecorded interface or a mocked agent loop. The demo you click is that same deployment, running on persistent infrastructure with durable state and its availability is independently visible on the public status page

The strongest result is that the controls visibly affected real outcomes:

  • 3 of 5 genuine published repairs recorded 'REMAND → CLEAR'.
  • 7 of 10 genuine GPT-5.6 readiness runs had at least one 'REMAND'.
  • The genuine tampered-evidence boundary held in 1/1 production case, with no false approval of the injected instruction.
  • 14/14 synthetic sanitizer vectors were neutralized.
  • 34/34 synthetic broker-authority tamper cases were rejected before side effects.
  • 1/1 expired warrant and 1/1 reused warrant were denied.
  • 1/1 semantically duplicate failed repair was refused.
  • The sealed readiness cohort produced 10/10 verifiable signed exports.

The tampered-evidence case is especially important to me. CrossPatch did not indiscriminately block the legitimate repair. It denied authority to the hostile instruction, preserved the useful operational signal and still moved the legitimate fix through 'CLEAR → human approval → VERIFIED'.

The current keyless release evidence records 899 Python passes—872 backend/victim tests plus 27 claim-map tests—with 28 skips; 318 UI tests passed, and 5 browser E2E tests passed with one capture-generator test skipped. Material public claims are bound to machine-generated artifacts in the repository rather than hand-authored screenshots or invented demo output. From a fresh clone, make eval re-derives the canonical SHA-256 and independently reproduces the evaluation metrics above.

What I learned

The biggest lesson was that trustworthy agentic software is not created by one perfect system prompt. Trust comes from separating reasoning from authority.

Models can investigate, challenge and propose. Deterministic software must control evidence boundaries, state transitions, mutation, test execution and proof. A human should approve a concrete, immutable document - not a vague intention.

I also learned that failure is often the most convincing demonstration of an AI system. A visible 'REMAND', 'ABSTAIN', rejected warrant or failed test shows whether the architecture genuinely holds when the happy path breaks.

Working with Codex was most effective when I supplied explicit invariants and made the important product decisions myself. The combination of human direction, testable contracts, independent review and persistent iteration produced something much more substantial than generating code from a single prompt.

What's next for CrossPatch

The next step is to extend CrossPatch beyond the two bundled webhook scenarios:

  • Add evidence-ingestion adapters for real observability platforms, issue trackers and source-control systems.
  • Support additional languages, repositories and immutable verification plans.
  • Add organization-level identity, team approval policies and enterprise audit integrations.
  • Expand the library of failure scenarios while preserving the same human gate and deterministic broker.
  • Invite external SRE and security teams to review the warrant format, isolation boundary and published case-file verifier.

The long-term goal is straightforward: let AI help teams repair incidents faster without asking those teams to surrender execution authority or trust an agent's unsupported claim that its own work passed.

Built With

Share this project:

Updates