Claude Code harness setup

Claude Code says it’s done. I make it prove it.

I install a gate that sends back any reply whose claims don’t match what actually ran. Fixed price, from €1,500.

Book a setupRead the incidents
The feeler that found a missing checkPins: checks the reply can proveA reply rises from the agent’s lift with one pin for each check it passed. Four feelers drop onto the pins. One missing and its feeler sinks into the empty socket: the lamp lights and the reply goes back until it is finished.

What goes into your repo

Each part catches one way Claude Code fails without telling you. All of it is settings, hooks, scripts and docs committed to your repo. Nothing depends on my machine.

  • Completion gate

    A Stop hook has a second model read each reply before it reaches you. A claim of done with nothing run behind it goes back to the agent.

  • Evals and canaries

    A few fast cases that prove the agent still knows what your instruction files say. They run after every edit to those files and before every deploy.

  • Hooks

    Guards on tool calls: no reading secrets, no builds in a live directory, no tools at all for headless jobs. Each one is shown to fail closed.

  • Long-term memory

    One index the agent reads every session, a line per memory, with the detail in separate files. Entries nobody uses get pruned on a schedule.

  • Scheduled agent jobs

    Recurring work runs headless with locked-down tools, and it reports when it fails, not only when it succeeds.

  • Phone control surface

    Results and approvals reach your phone as one message per event, with buttons for the decisions.

A canary that lost its factThe instruction file, punched with four factsThe instruction file is the card and each canary is a pin that must pass through a fact on it. An edit that drops a fact leaves one pin standing on the card: the head cannot bottom out, and the deploy bolt stays in its keeper until the file and the canary agree again.

Incident log

Every check I install is there because that failure already happened to me, on the Mac mini that runs my own agents, including the chat agent I use from my phone. Here are six of those incidents, written up as postmortems.

completion gate

The gate that judged nothing for five days

What broke
Every reply was meant to pass a second-model review before it reached me. All 124 reviews timed out: the budget was 8 seconds, and a bare judge call on that machine takes 4 to 6 before the real prompt is added.
How it was found
A duration column stuck at about 8,010 ms on every row. The gate had failed open and logged each timeout as a normal approval.
What runs now
The budget comes from a measured floor (now 30 seconds), every fail-open records its reason, and one query proves the gate is alive.

headless jobs

“No tools” that meant every tool

What broke
A nightly eval job ran claude -p --allowedTools "" and its comments said that meant zero tools. The empty value is dropped, so every tool stayed live. One run built a 229 MB Python environment from a spec it made up.
How it was found
While hardening the job. Blocking Bash alone did not help: the model reached the shell through another tool.
What runs now
Headless jobs carry a deny-all PreToolUse hook written inline in their settings, so there is no script file that can go missing and fail open. An audit then found four more jobs with the same flag.

canaries

Two deploys refused after a tidy-up

What broke
A cleanup of the agent’s memory index rewrote one line and dropped the hostname a canary asks about. The deploy gate refused two deploys with “context canaries 3/4”.
How it was found
The canaries caught it, as designed, and a control call ruled out a quota blip. But it only surfaced three minutes into a build, where it looked like a code regression.
What runs now
The four canaries run in about 35 seconds after any edit to the instruction files, before a deploy. When a canary and a doc disagree, both get fixed. The canary is never loosened.

deploy gate

A red gate that left the dashboard half deployed

What broke
The pre-swap check said no, but the build had already overwritten the live directory. The browser got the new UI, the running server kept its old route table, and every new API call returned 404.
How it was found
Only after the second “still 404”. A log line saying the gate is red and nothing was swapped reads as “nothing changed”.
What runs now
A deploy lock stops a second deploy before it builds, and a red gate restores the previous build without a restart. The restore was proven by planting a marker file and watching it disappear.

runtime upgrade

Health checks green, dependencies dead

What broke
A Homebrew Node upgrade moved native modules to a new ABI, 141 to 147. Every compiled addon on the machine stopped loading.
How it was found
Not by the health checks. Running services keep the old binary in memory, so they kept answering 200, one of them for two days. A nightly job that starts fresh failed first.
What runs now
Every Node upgrade includes a sweep of all native addons, and each fix is tested on a scratch port against a copy of the database, never the live file.

verification

A green log from the run before

What broke
The agent tailed the deploy log, saw “post-swap GREEN” and reported the deploy verified. That block belonged to the previous run. The new build had not even been staged.
How it was found
By checking artifacts: the build directory’s timestamp, the bundle hash and a missing route all disagreed with the log.
What runs now
A deploy counts as verified only from artifacts: the bundle hash being served, the new route on disk, a process that started after the build. Logs are read from the current run’s header down.

One setup, one price

from €1,500

Fixed scope, agreed in writing before I start. No hourly billing.

Book a setup

Included

  • Completion gate on your Stop hook, its time budget measured on your machine
  • Canary evals for your instruction files, wired into deploys or CI
  • Guard hooks for secrets, live directories and headless jobs, each shown to fail closed
  • A memory index with a pruning schedule
  • One scheduled agent job of your choice, reporting to your phone
  • Results and approvals on your phone, one message per event
  • A README in your repo for every part
  • A handover where each check is made to fail once, in front of you

Bigger than one repo?

More repos, more jobs, or 30 days of tuning after handover, where every repeat failure becomes a new check. You get a fixed quote for that before we start.

How it runs

  1. You tell me what keeps breaking

    A few lines about your repo, your Claude Code setup and the failures you see.

  2. I send a fixed quote

    Scope and price in writing, from €1,500. You decide before any work starts.

  3. I build it in your repo

    Settings, hooks, scripts and docs, committed where your team already works.

  4. Every check fails once, in front of you

    At handover I break each check on purpose, so you see it catch the failure. Then it is yours.

Tell me what keeps breaking.

Email a few lines about your setup and I reply with a fixed scope and price.

Book a setup

omar.portero.nassar1@gmail.comOr message me on X: @GodelTrabuco69

The email opens like this

To
omar.portero.nassar1@gmail.com
Subject
Claude Code harness setup

Repo and stack:

Team size:

What keeps breaking: