Motivation

There are many coding harnesses (Claude Code, Codex, and many more), but they are all designed to be used by a human.

They are not designed to be used by an agent. If you ask an agent to use codex exec as a subagent, it might spend a few turns just to figure out the right CLI flags and parse the output. And if you want a more custom loop, an agent might need even more turns to dig into the source code of Codex CLI to learn all the implementation details.

Harness In Prompt

hip-agent (harness in prompt) is a harness designed for agents. The core loop is about 200 lines of Python, plus one module for the Codex API. Three ideas:

• The harness fits in the prompt. The loop is minimal, the model is given only two tools, sh and view_image, and the prompt tells it to read the source to learn exactly what the harness does.
• The OS is the runtime. Configuration is environment variables, actions are shell commands, and a subagent is a child process.
• The rest is handled by existing protocols and formats. Plugins follow Agent Plugins, hooks use Claude Code’s hook contract, and the conversation is a Codex CLI session file, so codex resume opens it.

The whole configuration looks like this:

# ~/.zshrc
P=~/hip-agent/plugins
export AGENT_MODEL=gpt-5.6-sol
export AGENT_PLUGINS=$P/environment:$P/cwd:$P/agentsmd

And a run:

codex login
./agent "inspect this repository and explain it"

Everything else comes naturally from this design:

• A subagent is agent run from sh. It inherits the environment and gets its own conversation. The parent configures it with environment variables, AGENT_MODEL=... agent "...". By default the parent sees only the subagent’s final output, but its state can be read from its session file, and more advanced interactions can be implemented as plugins.
• The harness is repairable. A sufficiently smart model that has read its harness can work around its limits, or change them.
• You can put hip-agent in a skill and let your existing agent spawn subagents through it. The code itself is the documentation.

Why not native subagents?

Why a new harness when current models are already trained with subagents?

1. Models don’t always perform best in a fixed harness, and as models get better a fixed harness can become the limitation. hip-agent is not a fixed harness. It is a reference implementation, deliberately small so that an agent can read, modify, and adapt it.
2. You can train the model to use it. Future models can follow the hip-agent approach, building and editing their own subagent harness depending on the task.

Results

I did a few iterations of the code on Terminal-Bench 2 with gpt-5.6-luna at effort max: improved the shell design and the prompt a bit, added the view_image tool and command timeouts. Otherwise the code and prompt changes were minimal and not bench-maxxed.

The final code was then evaluated on DeepSWE, 113 tasks, against a Codex CLI 0.147.0 baseline. The results show hip-agent performs comparably with Codex CLI.

One run each, no error bars. The two runs ran concurrently on two local machines with the same CPU but otherwise different hardware. Token usage is not compared because hip-agent does not log it.

Conclusion

Almost every model provider now ships its own TUI harness. But nobody has time to try them all.

It also makes evals hard. A benchmark run measures the model and the harness together. OpenAI found that ARC-AGI-3’s harness dropped the model’s reasoning between moves. Turning on two settings that Codex uses by default tripled the score. On the other hand, a user-facing harness changes every week, and not every change is an improvement: Anthropic’s April postmortem documented how a harness can silently degrade the result when the model is unchanged. A user-facing harness is therefore a poor instrument for evaluating a model.

Ideally, every model builder would ship a minimal native reference harness, like hip-agent. A native reference harness is like a tool parser or a chat template: it describes how the model was trained to interact with the world. It should be separate from the model provider’s user-facing product. It also makes trying a new model easy: a user can ask their existing agent to run the new model as a subagent.

Related work

• mini-swe-agent shares the bash-only principle and has a ~100 line core, but it is designed with abstractions to work with any model and environment. hip-agent commits to one provider and one OS. This keeps the full code smaller and allows vendor-specific features like Codex’s compaction and resumable Codex sessions.
• llmproc and agent-environment-middleware are my earlier work exploring agent harnesses and abstractions like plugins.
• Codex app server is the low-level interface Codex CLI and the other Codex apps use (the VS Code extension, the desktop apps). It bundles a lot of app-specific logic and is not a lowest-level reference for the model loop. I had an agent dig into it to figure out the correct way to use compaction, the websocket API, etc.