The Portable Harness

The riskiest dependency in an AI workflow is not the model. It is the harness wrapped around it: the program that reads files, runs commands, applies edits, and decides what the model is even allowed to touch. When that harness belongs to a vendor, its behavior can change without notice. A UI is redesigned, a permission default flips, an execution boundary moves, and a pipeline that passed every test last week now fails in production for reasons that live on someone else's roadmap.

For a system architect responsible for secure workflows, that exposure is the whole problem. The value of a coding agent is not measured only by how fast it scaffolds a project or automates a data pipeline. It is measured by whether the same agent will behave the same way in six months, inside the same restricted sandbox, under the same rules. Terminal-native, open-source agents are worth attention precisely because they let that guarantee be owned rather than rented.

A harness you can read, pin, and rebuild is insurance. A harness you can only accept is a liability that compounds every time it changes underneath you.

The harness is the surface that moves

Two projects illustrate how small a dependable harness can be. pi, released by Mario Zechner in August 2025, is a deliberately minimal coding agent. Its instruction prompt is kept under a thousand tokens, it ships with roughly four built-in tools (read, bash, edit, write), and everything else is added through TypeScript extensions. The design bet is that a capable model needs little scaffolding, so the core stays small enough to audit in an afternoon.

oh-my-pi (invoked as omp) is a fork of that core by Can Boluk, rewritten in roughly 27,000 lines of Rust under an MIT license. It keeps the minimal spirit but wires in the parts a working engineer misses: hash-anchored edits that refuse to apply when the target text has drifted, Language Server Protocol diagnostics so the agent sees the same type errors an IDE would, Debug Adapter Protocol support for stepping through failures, and subagents for parallel work. Both are installed and run from the terminal, and both keep their state on the local machine.

The point is not that either tool is the correct choice for every team. The point is that their behavior is legible. The prompt, the tool list, and the permission model are files that can be read, forked, and pinned to a known commit. Nothing about them shifts unless the version is changed on purpose.

Open source is not the same as unmanaged

It helps to separate two axes that often get collapsed. One axis is proprietary versus open source. The other is managed for you versus self-hosted by you. Claude Code, for example, is a proprietary agent, while OpenCode is open source. Both are excellent, and neither claim here is that they are unsafe. The argument is narrower: control over the harness follows the second axis, and a self-hosted open-source agent is the only combination that puts the execution boundary fully in the operator's hands.

RENTED HARNESS

• Behavior set by a vendor roadmap
• Defaults and UI can change without notice
• Execution boundary owned elsewhere
• Portability limited to what is exported

OWNED HARNESS

• Behavior pinned to a known commit
• Prompt and tool list are auditable files
• Sandbox rules written by the operator
• Same agent runs anywhere the terminal runs

A managed platform can still be the right default for most work. Speed, polish, and a maintained update path are real benefits. The case for keeping an open agent in reserve is a hedge, not a rejection: when a critical workflow must not move, it should sit on a foundation the operator can freeze.

Building a restricted harness around an open core

The practical move is to treat an open agent as a component, not a product, and to wrap it in a thin harness that encodes local security policy. Because the core is small and its tools are explicit, the wrapper can be small too.

A restricted harness usually does a few concrete things. It pins the agent to an exact version so no upstream change lands unreviewed. It narrows the tool set to only what the task needs, removing anything that can reach the network or the wider filesystem. It runs the whole thing inside an isolated sandbox, a container or a locked-down user account, so the blast radius of any command is bounded. And it logs every tool call so the run can be audited after the fact.

# pin the agent, then run it under a locked-down policy
npm i -g @oh-my-pi/pi-coding-agent@<pinned-version>

# isolated, no network, read-only except one work dir
docker run --rm --network none \
  --read-only -v "$PWD/work:/work:rw" \
  omp-sandbox omp --allow read,edit,bash --cwd /work

The specifics vary by environment, and the commands above are only a sketch. What matters is the shape: the agent is a pinned dependency, the permissions are declared by the operator, and the isolation is enforced by infrastructure the operator already trusts. None of that is available when the harness is a remote service whose internals cannot be seen.

PINLock the agent to an exact, reviewed version

→

RESTRICTExpose only the tools the task requires

→

ISOLATERun inside a sandbox with a bounded blast radius

→

AUDITLog every tool call for later review

Portability is the real payoff

Because the agent talks to any model provider and keeps no hidden state in the cloud, the same wrapped harness runs on a laptop, a build server, or an air-gapped machine with only a configuration change. A workflow validated once can be reproduced anywhere the terminal runs. That is what makes the setup a genuine hedge: if a provider raises prices, changes terms, or deprecates a feature, the harness stays put and only the model behind it needs swapping.

The trade is real and worth stating plainly. Owning the harness means owning its maintenance: security patches, upstream fork merges, and the discipline to review each version before pinning it. For a throwaway script that cost is not worth paying. For the small number of workflows that must stay stable, isolated, and portable, it is the cheapest insurance on offer, and it is paid once rather than every time a vendor decides to move.

What leaders should do

1. Identify the two or three workflows that genuinely cannot tolerate an unannounced harness change, and treat only those as candidates for a self-hosted agent.
2. Pin any open agent to an exact reviewed version and run it inside an isolated sandbox with the tool set narrowed to what the task needs.
3. Keep a managed platform as the default for everyday work, and reserve the owned harness as a tested fallback rather than a wholesale replacement.
4. Budget for the maintenance the choice creates: assign an owner for upstream reviews, patches, and the periodic re-validation of the pinned build.