A Claude Code Harness You Configure, and the Open-Source Platform You Own

What a harness owns in Claude Code

Claude Code runs in the terminal, in VS Code and JetBrains extensions, in a desktop app and on the web. All four reach one engine, and that engine is a harness. Anthropic defines it as "the software scaffolding around a model: the loop, tools, context management, and guardrails that turn raw intelligence into a working agent" (Anthropic).

The model is the part you rent by the token. The harness decides how many turns it gets, what it can touch, what it remembers and when it stops. Two teams on the same model get different output because their harnesses differ. Most of that difference is configuration.

In Claude Code the harness is Anthropic's own code. Anthropic does not publish it. What you can change is the five layers around it, and those layers are where harness engineering happens.

The five layers people configure

Memory. CLAUDE.md is a markdown file at the project root, read at the start of every session. It carries coding standards, architecture notes and review checklists. A repository with an AGENTS.md can have Claude Code read that instead (overview).

Tools. Three sources feed the loop: the built-in Bash and file tools, MCP servers that reach outside systems, and skills that package a repeatable workflow.

Permissions. JSON settings files hold allow, ask and deny rules. A default mode decides which tool calls run without a prompt (settings).

Hooks. Shell commands run at fixed points in the lifecycle. A PreToolUse hook that exits with code 2 blocks the action before it runs. That is the deterministic half of guardrails: the model gets no vote (hooks).

Observability. Claude Code exports OpenTelemetry metrics and events, plus optional traces that link a prompt to the calls it caused. Tracing is off by default, and spans redact prompt text, tool input and tool content until you switch that on (monitoring).

Four layers describe what the agent knows and can reach. The fifth decides what it may do.

Where the configuration lives

Settings come from four places. Each covers a different set of people. ~/.claude/settings.json covers every project on your machine. A committed .claude/settings.json covers anyone who clones the repository, once the folder is trusted. .claude/settings.local.json covers you alone and stays out of your commits. Managed settings cover every machine an organisation deploys them to.

The local file deserves attention, because Claude Code writes it itself. Ask about a Bash command and answer "Yes, and don't ask again", and the approval lands there as an allow rule. The harness then treats the command as pre-approved, on your machine, in a file your team never opens.

An allow list that forms this way records what one person needed one afternoon. Nobody reviews it, because it never enters the repository. It also outlives the task that produced it.

The permission default decides the outcome

Permission modes set the baseline. In Manual mode, Claude Code stops and asks before most actions that edit files, run shell commands or reach the network. Since v2.1.283, auto mode is the built-in starting mode for interactive terminal and VS Code sessions. A classifier model reviews actions instead of you (permission modes, checked October 2026).

Rules layer on top, and order matters. Claude Code evaluates deny first, then ask, then allow, so the first match decides. A broad deny rule beats a narrow allow rule. An allow rule cannot carve an exception out of a deny. The documentation says plainly that Claude Code enforces the rules, not the model: prompt text and CLAUDE.md shape what the agent tries, not what the harness permits (permissions).

Read those two facts together and the default becomes visible. The starting mode hands approval to one model for the actions of another. The rules that gate a write start empty and fill with whatever got approved once.

For a person at a laptop that is a fair trade. You watch, and you can interrupt. For work that writes, in a queue, with nobody at the keyboard, it is the wrong place to begin. An agent that starts from allow has a permission set nobody chose.

The other order is dull and it holds. Deny by default, allow by name, commit the list, and keep the approvals that matter on a path a person reads. It costs a few prompts in the first week.

What deny by default looks like in a repo

Kortix is the open-source AI Operating System. Its project manifest takes that second route. The v2 kortix.yaml is governance only: one agents: map per project, holding the grants an agent gets and the path of the markdown file that describes its behaviour. An omitted grant resolves to none, so an agent scoped to one job starts with nothing.

The starter's own default agent is granted everything on purpose. The file says why: a fresh project should be capable before anyone has read the docs. Narrowing that block is the first edit most teams make.

The second switch is separate. Approval gates you set. Off until you set them. Grant scope decides what an agent may reach. The gate decides whether a person is asked before a tool call runs. A project can deny every grant and still leave the gate open. It can also scope an agent narrowly and gate the one call that matters.

The manifest itself is short. Agents are one markdown file each. Skills, memory and tools sit at the project root, so a change of harness does not rewrite them. The configuration is a repository you own: your agents, the skills they share, your company memory, and every connector live in one git repo.

Kortix gives you an isolated sandbox per session, on its own branch. An agent's experiments stay somewhere you can inspect before anything lands.

Which shape fits the work

Two questions sort most teams. Who approves a tool call when nobody is at the keyboard, and where does the record of that approval live six months later?

If the answers are "the engineer who started it" and "in that engineer's home directory", Claude Code's own layers are enough. Commit .claude/settings.json. Read the allow rules before they accumulate. Put a hook in front of files that must not change. Send telemetry to a collector you control.

If the answers are "a reviewer" and "in the repository, in a change request", the shape changes. Grants, gates and session history have to be readable by someone who was not in the room. That calls for a platform whose harness code you can read, and for configuration that lives in the repository rather than in four dotfiles on four laptops.