My personal coding-agent configuration: Claude Code first, plus Codex CLI and OpenCode. There is no installer, but the wiring is deliberately simple. A dozen symlinks, documented in SETUP.md, no hardcoded paths. The persona is mine: fork and edit.
Three layers: a behavior contract every harness loads, a build workflow that decides where work runs, and a little cockpit trim.
The same behavior file reaches Claude Code, Codex CLI, and OpenCode, and a directive only stays if the harness running it doesn't already enforce it. Keeping that true takes machinery: harness system prompts change under you, so they're snapshotted, diffed, and the file is audited against them.
- AGENT_BEHAVIOR.md: the behavior file. A routing header keys its sections to the harness and model actually running: a SHARED core everywhere, model sections for Claude Code, a minimal section for harnesses whose own prompts cover less.
- CLAUDE.global.md: the
~/.claude/CLAUDE.mdtarget. It carries the@-import that delivers the behavior file to Claude Code, plus a placeholder for durable preferences. Codex and OpenCode consume the file viaAGENTS.mdsymlinks. - audit-directives/: the audit skill. It snapshots live harness prompts, diffs them against the committed copies, and classifies every directive as absent, duplicate, or conflict, so directives that stop earning their keep get removed instead of rotting.
- harness-snapshots/: the committed prompt corpus those audits diff against, with provenance and upstream licenses in its README.
- bin/fetch-harness-prompts: deterministic snapshot fetcher; a refetch with no upstream change leaves the tree byte-identical.
Pro/Max plans share one usage pool and models differ in strengths, so the build loop is split: judgment (planning, review) stays on the strongest model, implementation volume goes to Opus, and breadth review runs on external harnesses, under OS-level confinement (see Sandboxing).
- opus-build/: the split build workflow. Plan and review on the main loop, build on fresh Opus subagents at xhigh effort, breadth-review on whichever external lanes are installed (Codex, Kimi K3, a sandboxed Opus). On a Fable main loop the split is about budget; on an Opus main loop it is about context, and the skill states which mode it is in. review-2026-07-27.md is the adversarial review from its first validation run; sandbox/ confines the headless review lanes.
- agents/opus-builder.md and agents/opus-reviewer.md: the pinned-model build and review agents it dispatches to.
- commands/iterate.md: the discovery-driven loop for fuzzy-scope work (frame, build, evaluate, decide). Its premise: in discovery work the spec is an output, written at convergence rather than guessed up front.
- trim/statusline.js: status line script.
- trim/statusline.test.sh: renders the status
line against crafted payloads and asserts the colour band. Run it directly;
STATUSLINE=/path/to/other.jspoints it at another build for comparison.
Agents here run under OS-level confinement (macOS Seatbelt), scoped by trust and supervision rather than model goodwill:
- The opus-build K3 reviewer, an open-weight model running headless
through OpenCode (which has no OS sandbox of its own), is wrapped in
Anthropic's
@anthropic-ai/sandbox-runtimeby opus-build/sandbox/k3-review.sh: repo readable but not writable, writes confined to OpenCode's own state dirs and temp space, network confined to the Kimi API. Fails closed when srt is missing rather than degrading to an unsandboxed run. - The Codex reviewer is OS-sandboxed read-only by its plugin's own default, pinned in the opus-build skill so a plugin update that widens that default gets surfaced, not silently absorbed.
- The Opus reviewer gets the same treatment by opus-build/sandbox/opus-review.sh, which is the standard Phase 4 Opus path. Sandboxing a reviewer while build subagents write files unsandboxed sounds inconsistent, but it is just least privilege: builders need write access to do the job and reviewers never do.
- Everything else, the main loop and Opus build subagents included, runs with Claude Code's own permission prompts. Its native Bash sandbox is available and documented in SETUP.md, but it is opt-in and off in my settings: it trades prompts for a boundary, which pays off only when your work mostly stays inside one.
The premise: a git worktree is merge hygiene, not a security boundary. Any
agent that runs npm install or a test suite executes third-party code with
your whole account. So the boundary is mechanical wherever a lane runs
headless or on a model without Claude's safety training; permission prompts
only govern sessions a human is actually watching. Where a sandbox is on it
is also an enabler and not only a shield: inside the boundary, commands
auto-run without permission friction.
See SETUP.md: everything is symlinks from harness config directories into this clone. Only Claude Code and those symlinks are required; every other tool here is optional and retires just the lane that needs it. bin/doctor reports what is installed and which lanes that leaves live, which is also the fastest way to see what a partial install gets you before committing to one.
The ### IDENTITY section of AGENT_BEHAVIOR.md (the R. Daneel Olivaw
persona) is adapted from Bill Burdick's
zot/humble-master (MIT); rewrite it
to taste. The transferable ideas are the routing header, the audit skill,
and the budget-split workflow.
MIT (LICENSE). harness-snapshots/ contains third-party prompt
text redistributed under upstream licenses; see
its README.