Require [core] harness rather than defaulting to claude-code #121

2026-08-11T19:56:00-07:00

dejima-agent commented

2026-08-11 19:56:00 -07:00

Summary generated by LLM agent

Not the existing behaviour - it defaulted to claude-code:

core.harness	provider:harness	claude-code

Now it has no default and dejima refuses to start without it:

[core] harness is not set in /home/you/.config/dejima/config.

There is no default: which harness runs your session is a choice
dejima will not make for you, so that a future release adding one
cannot change it without you noticing. Add to that file:

  [core]
  harness = claude-code

Available: claude-code

The starter config already had your reasoning

install.sh writes forge and workflow uncommented, with this comment:

written out uncommented, so this file states what it selects rather than inheriting whatever a future release defaults to

harness now gets the same treatment, and the comment says it has no default at all. A fresh install is explicit; only existing configs need the one-line addition.

One thing that had to change to keep --print-config working

The schema enumeration resolves [harness.<name>] keys through the selected name, so an empty one made it print invalid harness name: - meaning the command an operator would reach for to find out what is unset failed on the thing being unset. An unselected axis now contributes no keys, which is a different question from whether a selection is valid. There is a test for it.

Test fixtures

This is a breaking change for any config without the key, and the test suite was full of them - ~50 failures, all one cause. Every fixture that launches now selects a harness, as a real config must. The three suites with a launch helper seed it there; the few that write a config directly say it themselves.

config.bats' write_config seeds it only when the caller has not. Worth knowing how I got that wrong first: I matched *harness* against the arguments, and a [mounts] read_write path containing the string (my worktree was /tmp/harness) suppressed the seeding and failed a test for a reason nothing named. It now matches a key assignment.

New tests: the refusal names the file and the line to add; the schema carries no default; --print-config survives it being unset. The first two write their config directly, since write_config seeds a harness by design.

785 pass across config, providers, project, static, remote, audit.

For you

Your own ~/.config/dejima/config needs harness = claude-code adding before this merges, or your next launch refuses. That is the intended behaviour, but it will be your own first encounter with it.

**Summary generated by LLM agent** **Not the existing behaviour** - it defaulted to `claude-code`: ``` core.harness provider:harness claude-code ``` Now it has no default and dejima refuses to start without it: ``` [core] harness is not set in /home/you/.config/dejima/config. There is no default: which harness runs your session is a choice dejima will not make for you, so that a future release adding one cannot change it without you noticing. Add to that file: [core] harness = claude-code Available: claude-code ``` ## The starter config already had your reasoning `install.sh` writes `forge` and `workflow` uncommented, with this comment: > written out uncommented, so this file states what it selects rather than inheriting whatever a future release defaults to `harness` now gets the same treatment, and the comment says it has no default at all. A fresh install is explicit; only existing configs need the one-line addition. ## One thing that had to change to keep --print-config working The schema enumeration resolves `[harness.<name>]` keys through the selected name, so an empty one made it print `invalid harness name:` - meaning the command an operator would reach for to find out *what is unset* failed on the thing being unset. An unselected axis now contributes no keys, which is a different question from whether a selection is valid. There is a test for it. ## Test fixtures This is a breaking change for any config without the key, and the test suite was full of them - ~50 failures, all one cause. Every fixture that launches now selects a harness, as a real config must. The three suites with a launch helper seed it there; the few that write a config directly say it themselves. `config.bats`' `write_config` seeds it only when the caller has not. Worth knowing how I got that wrong first: I matched `*harness*` against the arguments, and a `[mounts] read_write` path containing the string (my worktree was `/tmp/harness`) suppressed the seeding and failed a test for a reason nothing named. It now matches a key assignment. New tests: the refusal names the file and the line to add; the schema carries no default; `--print-config` survives it being unset. The first two write their config directly, since `write_config` seeds a harness by design. **785 pass** across `config`, `providers`, `project`, `static`, `remote`, `audit`. ## For you Your own `~/.config/dejima/config` needs `harness = claude-code` adding before this merges, or your next launch refuses. That is the intended behaviour, but it will be your own first encounter with it.

dejima-agent added 1 commit 2026-08-11 20:38:32 -07:00

Require [core] harness rather than defaulting to claude-code

tests / runner-env (confined) (pull_request_target) Successful in 32s

Details

tests / confined (proxy) (pull_request_target) Successful in 1m4s

Details

tests / confined (static) (pull_request_target) Successful in 2m38s

Details

tests / confined (providers) (pull_request_target) Successful in 3m27s

Details

tests / confined (remote) (pull_request_target) Successful in 3m49s

Details

tests / privileged (pull_request_target) Successful in 4m19s

Details

tests / runner-env (privileged) (pull_request_target) Successful in 32s

Details

tests / confined (project) (pull_request_target) Successful in 5m0s

Details

tests / confined (config) (pull_request_target) Successful in 6m17s

Details

tests / confined (audit) (pull_request_target) Successful in 7m4s

Details

799dd3b6eb

The default was fine while claude-code was the only harness and stops being
fine the moment there is a second: an operator who never wrote the key made
no choice, and a release changing the default would move them silently on
upgrade.

dejima now refuses, naming the file, the line to add, and what is available.
install.sh writes it uncommented in the starter config, the same treatment
forge and workflow already get, for the reason already written there.

--print-config keeps working with it unset, which took one fix: the schema
enumeration resolved [harness.<name>] keys through the selected name and
printed "invalid harness name:" for an empty one. An unselected axis
contributes no keys.

Every fixture that launches now selects a harness, as a real config must.
config.bats' write_config seeds one only when the caller has not, matched as
a key assignment rather than as the word anywhere in the arguments - a
[mounts] path containing "harness" otherwise suppressed it.

dejima-agent force-pushed require-harness from 72a419689b to 799dd3b6eb

2026-08-11 20:38:32 -07:00

Compare

branderson approved these changes 2026-08-11 23:47:37 -07:00

branderson merged commit 13e8c39d0f into main

2026-08-11 23:48:02 -07:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima#121