Say which config line is broken instead of blaming the harness #183

Merged

branderson merged 1 commits from install-config-diagnosis into development 2026-08-22 21:25:29 -07:00

Conversation 1 Commits 1 Files Changed 2

+30 -2

dejima-agent commented 2026-08-22 21:01:34 -07:00

Collaborator

Copy Link

Copy Source

Summary generated by LLM agent

Reported from a real host: ./install.sh said "No [core] harness is set in ~/.config/dejima/config" to an operator whose config sets [core] harness = claude-code, on a checkout whose branch predated #180. The real fault was [harness.cline] context_window, a key that branch did not yet know.

A config that does not parse leaves config_get empty for every key, so the harness read came back empty and got reported as "no harness set" - sending the operator to a line that was already correct, with no way to tell from the message that the file had not been read at all. The actual reason was on stderr the whole time and thrown away by a 2>/dev/null.

config_validate is now consulted first and its diagnosis left to reach the terminal, so the offending key is named. "No harness set" is still reported when that is genuinely the case, which is the upgrade path #157 added it for.

Worth stating because it is not a corner case: writing a config against a newer dejima than the checkout is exactly what an unrecognised key looks like from the older side, and it is the ordinary consequence of running a feature branch. install.sh is not the only casualty - dejima-ttyd exits 1 and takes the web front door down with it, which is where the same operator hit this next. Those tools already print the reason; install.sh was the one swallowing it.

Refusing on an unknown key is deliberate and unchanged here. A key silently ignored can be a guard silently not applied, so a config dejima cannot fully account for is one it should not act on.

Testing

test/run-confined.sh green (audit 158, config 141, conversation 11, project 137, providers 79, proxy 32, remote 107, static 334, zero failures).

One new test in test/config.bats, driving install.sh with a config that sets a valid harness and one unknown key: it asserts the output names the offending key, does not say the harness is unset, and that no guards were registered from a config that could not be read. It fails on the old code.

Verified by hand across all three paths against a stubbed docker and a scratch HOME: unknown key names the key, absent harness still says so, and a valid config still registers all four hooks.

**Summary generated by LLM agent** Reported from a real host: `./install.sh` said "No [core] harness is set in ~/.config/dejima/config" to an operator whose config sets `[core] harness = claude-code`, on a checkout whose branch predated #180. The real fault was `[harness.cline] context_window`, a key that branch did not yet know. A config that does not parse leaves `config_get` empty for **every** key, so the harness read came back empty and got reported as "no harness set" - sending the operator to a line that was already correct, with no way to tell from the message that the file had not been read at all. The actual reason was on stderr the whole time and thrown away by a `2>/dev/null`. `config_validate` is now consulted first and its diagnosis left to reach the terminal, so the offending key is named. "No harness set" is still reported when that is genuinely the case, which is the upgrade path #157 added it for. Worth stating because it is not a corner case: writing a config against a newer dejima than the checkout is exactly what an unrecognised key looks like from the older side, and it is the ordinary consequence of running a feature branch. `install.sh` is not the only casualty - `dejima-ttyd` exits 1 and takes the web front door down with it, which is where the same operator hit this next. Those tools already print the reason; `install.sh` was the one swallowing it. Refusing on an unknown key is deliberate and unchanged here. A key silently ignored can be a guard silently not applied, so a config dejima cannot fully account for is one it should not act on. ### Testing `test/run-confined.sh` green (audit 158, config 141, conversation 11, project 137, providers 79, proxy 32, remote 107, static 334, zero failures). One new test in `test/config.bats`, driving `install.sh` with a config that sets a valid harness and one unknown key: it asserts the output names the offending key, does **not** say the harness is unset, and that no guards were registered from a config that could not be read. It fails on the old code. Verified by hand across all three paths against a stubbed docker and a scratch HOME: unknown key names the key, absent harness still says so, and a valid config still registers all four hooks.

branderson changed target branch from main to development 2026-08-22 21:25:08 -07:00

branderson added 1 commit 2026-08-22 21:25:08 -07:00

Say which config line is broken instead of blaming the harness ... b9e65838c5

A config that does not parse leaves config_get empty for every key, so
the harness read came back empty and install.sh reported that no harness
was set - to an operator looking straight at the harness line they had
just written, which was correct. The reason was on stderr the whole time
and thrown away.

The most likely way to arrive here is a config written for a newer dejima
than the checkout, since an unrecognised key is exactly what that looks
like from the older side.

branderson approved these changes 2026-08-22 21:25:19 -07:00

branderson merged commit 2de990e2a6 into development 2026-08-22 21:25:29 -07:00

Sign in to join this conversation.

Reviewers

No Reviewers

branderson

Labels

Clear labels

Compat/Breaking

Breaking change that won't be backward compatible

Kind/Bug

Something is not working

Kind/Documentation

Documentation changes

Kind/Enhancement

Improve existing functionality

Kind/Feature

New functionality

Kind/Security

This is security issue

Kind/Testing

Issue or pull request related to testing

Priority

Critical

1

The priority is critical

Priority

High

2

The priority is high

Priority

Low

4

The priority is low

Priority

Medium

3

The priority is medium

Reviewed

Confirmed

1

Issue has been confirmed

Reviewed

Duplicate

2

This issue or pull request already exists

Reviewed

Invalid

3

Invalid issue

Reviewed

Won't Fix

3

This issue won't be fixed

Status

Abandoned

3

Somebody has started to work on this but abandoned work

Status

Blocked

1

Something is blocking this issue or pull request

Status

Need More Info

2

Feedback is required to reproduce issue or to continue work

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

branderson dejima-agent

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima#183