QuietHarness: a 1,604-byte behaviour layer for Claude Code, Codex and Cursor

The failure QuietHarness is built around

The README names five behaviours it exists to prevent: an agent overwriting files without checking existing changes, reporting a task complete without running tests, turning a small edit into an unnecessary refactor, performing deletes, publishes, production changes or credential operations without stopping to confirm, and forcing you to rewrite the same basic boundaries every time you switch agents. That last one is the packaging problem rather than a model problem. Each client reads its own configuration file, so the same intent has to be expressed three ways and kept in sync by hand. QuietHarness compresses the intended behaviour into a shared Core and then adapts it per client. The stated audience is people maintaining real projects with any one of Claude Code, Codex or Cursor. The README is direct that multi-client support is not an installation requirement: one client is enough to get the core boundaries, and portability is what you keep if you later change tools. It also states plainly what the project is not, namely a full task database, background automation or a team orchestration platform.

One Core, three adapters, and what is actually inside

The repository layout is three resident templates. The shared Core is templates/shared/AGENTS.md at 1,604 bytes. Claude Code uses templates/claude/CLAUDE.md at 168 bytes, described as a thin entry point that references the shared file. Cursor uses templates/cursor/quiet-harness.mdc at 546 bytes, mirroring the same boundaries in the format Cursor project rules expect. The README gives the combined figure as 2,318 bytes and notes that no single client loads all three. It also makes a scoping claim worth repeating: the comparison is file bytes, not tokens, speed or model quality. The Core content is four rules. Advance the current request directly. Do not pretend to have read files, pages or history you have not seen. Verify by risk after file or code changes. Confirm first for money, accounts, public releases, production environments and destructive actions. Codex reads the shared AGENTS.md directly, which is why its project install writes one file instead of two. The Claude adapter exists because Claude Code reads CLAUDE.md, so the installer writes both AGENTS.md and CLAUDE.md into the target directory to keep the reference intact.

Installing into a throwaway directory first

The README's onboarding path is deliberately sandboxed. Clone the repository, run ./scripts/inventory.sh, then create a temporary directory with mktemp and run ./examples/first-success/setup.sh against it. From there you pick exactly one client. For Claude Code the pair is ./scripts/install.sh --dry-run --claude-project "$demo_dir" followed by the same command with --apply. For Codex it is --codex-project, which writes only $demo_dir/AGENTS.md. For Cursor it is --cursor-project, which writes only $demo_dir/.cursor/rules/quiet-harness.mdc. The installer previews by default and writes only on an explicit --apply. It does not go online, does not log into an account, and does not modify a scheduler. The acceptance test is a single prompt, "Read TASK.md and complete the task." Success means the agent notices and preserves an unrelated user change, fixes only the discount calculation, runs the existing tests, and shows real verification evidence in its final reply without being told each step. The README is careful here and worth taking at its word: this is an onboarding behaviour check, not a causal experiment showing the harness improves the model. The design target is completion within ten minutes, and the README states that automation currently verifies only that the fixture is repeatable, with real non-author timing still an open product gate.

User-level installs, backups and the rollback procedure

Once the sandbox run passes, the README offers user-level targets. Claude Code user-level affects ~/AGENTS.md and ~/.claude/CLAUDE.md; Codex affects $CODEX_HOME/AGENTS.md, defaulting to ~/.codex/AGENTS.md. Before overwriting an existing file the installer creates a timestamped .bak-ai-workflow-* backup in place. The output convention matters for uninstall: each target prints INSTALLED <target>, and only targets that overwrote an old file print BACKUP <backup> immediately next to it. Uninstall is therefore per-target. If a BACKUP exists, restore that specific file. If no BACKUP exists, the target was newly created by QuietHarness, and the README says to confirm it still matches the template before removing that exact path, and to move it aside rather than delete it if you have since modified it. Rollback steps are documented in MIGRATION-v3.md. This is the strongest part of the project. Most dotfile-style agent configurations have no uninstall story at all, and the conditional restore logic is specific enough to follow without guessing.

The task and writer-lock model is a reference, not a runtime

The README describes a per-task record where status is the single lifecycle fact, owner_thread is stable business ownership, and primary_worker and claimed_by identify only the current executor. next_action, artifacts and updated_at must be explicit, and when new facts conflict with an old narrative, state_revision records the override. A worker saying it finished is not persistent state; there must be an artifact, validation and an owner writeback. Alongside that sits a single-writer rule: Claude, Codex and Cursor may investigate and review in parallel, but one repository or task fact surface has one writer by default. A repository write records repo, worktree, writer, allowed paths, validation and next gate; releasing the lock requires artifact, validation, writeback, rollback, outcome and next gate. The README attributes this to a real cross-model double-write incident. The constraint to understand is that these are documented conventions with example files (examples/leo-system/task.example.json, writer-lock.example.json) rather than an enforced service. Nothing in the supplied material shows a daemon, hook or validator that rejects a write violating the lock. If your team needs enforcement rather than agreement, this layer will not supply it.

What version 3 removed, and why that is the interesting decision

The README is unusually candid about the project's own history. The original open-source workflow accumulated rules, hooks, skills, memory, model routing, and named routines for morning, today and session end. Those additions solved real problems when models were less reliable. After the repository was published, the author kept iterating privately and the public copy fell out of sync. Returning to the highest reasoning settings, the README's account is that part of the old protection became duplicated planning, accidental process triggers and maintenance burden. Version 3 therefore removes rather than adds: resident configuration across three clients collapses to one small Core, project facts stay in the project and are read on demand, business and task continuity sit behind an explicit source of truth and a writeback protocol, and daily reports and monitoring keep running in the background without becoming a startup ritual. The name is the thesis. The harness still exists, but when no relevant task is running it should be quiet. That is a defensible position and also a risk: the reduction assumes current models can carry more path judgement, so on a weaker or cheaper model the same minimal Core may not hold the same line.

Alternatives and where the boundary sits

The natural alternative is to write your own AGENTS.md or CLAUDE.md by hand. The difference is not the content, since four rules fit in a paragraph you could write yourself. The difference is the surrounding machinery: a dry-run mode, per-target backup naming, conditional restore on uninstall, and three adapters that keep one source of truth across clients. If you only ever use one agent and never reinstall, hand-writing is simpler and has no shell script in the path. The project also points at its own larger alternative for a different problem. The OPC Company Layer under labs/opc-company is described as an experimental governance layer in the same repository, aimed at multiple long-lived owners and workers sharing canonical state, doing semantic handoff, rejecting false completion and continuing the same task after a worker swap. The README states it is not an installation prerequisite for QuietHarness. So the split is clean: QuietHarness is the behaviour boundary, and the company layer is the multi-agent governance experiment. The README also points to separately maintained repositories for prediction markets, asset due diligence, content ingestion and others, which are business branches rather than parts of the harness.

Maintenance cost, licence and what to check before trusting it

The licence is MIT, which permits modification and redistribution provided the copyright notice and permission notice are retained; that is a statement of the licence terms, not legal advice, and the LICENSE file is the authority. Maintenance cost has two parts. The templates are small enough to read in full, so auditing an update is cheap, but any change to templates/shared/AGENTS.md propagates into every installed target and the README does not describe an automatic update path, only install, backup and rollback. Expect to re-run the installer and reconcile backups at each version bump. The second cost is behavioural drift: because the Core is minimal by design, an agent that ignores it produces no error, which is exactly the failure the README acknowledges about session closeout, where a skipped step never throws an exception and the only usable test is whether a file was produced. The repository was last pushed in August 2026 with v3.1.0 released earlier that month, and the README states the ten-minute first-success target has not yet been timed by a non-author. That is the first thing to verify on your own machine, using the sandbox directory and the single TASK.md prompt, before installing at user level.

Editorial conclusion

Adopt QuietHarness if you already run one of these three agents on a real repository and you have watched it overwrite unrelated edits, declare a task done without running tests, or expand a one-line fix into a refactor. Skip it if you need a task database, scheduling, or team orchestration; the README states those are not provided, and the OPC Company Layer is explicitly an experimental governance layer rather than an install prerequisite. Before installing anywhere that matters, run ./scripts/inventory.sh, then ./scripts/install.sh --dry-run against the exact target and read the printed paths, because the user-level Claude target touches ~/AGENTS.md and ~/.claude/CLAUDE.md while the Codex target touches $CODEX_HOME/AGENTS.md. Then verify one thing the project itself flags as unproven: whether a non-author can reach first success in ten minutes, since the README says automation currently validates only that the fixture is repeatable.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. runesleo/claude-code-workflow on GitHub