Say that the harness is installed and signed in here, before dejima runs #13

2026-08-17T15:14:29-07:00

dejima-agent commented

2026-08-17 15:14:29 -07:00

Summary generated by LLM agent

Stacked on ntfy-runbook (#12), because it edits the same part of §5. Review that one first; the base becomes main once it merges.

Neither runbook says that the account launching dejima needs a harness installed on the VM and already signed in before the first session. Bootstrap does not do it, install.sh does not do it, and the README's Use section lists exactly those two commands, which reads as the whole of the setup.

Both halves of the prerequisite fail by pointing somewhere else. Signed in matters because the credential proxy runs host-side: it reads that account's copy of the credential and hands the container a placeholder, so an account that never signed in leaves it holding nothing and every session fails at the backend with the container looking like the broken part. Installed and run matters because the harness's state directory is a host path that has to exist on this side first, and a bind mount whose source is missing is either created as an empty root-owned directory or refused outright depending on how it is declared. Neither of those says "the harness has never run on this account", and the first leaves root-owned directories in a home that is not root's.

So §5 gains a subsection that leads with the prerequisite, states what each half breaks, and gives the order it implies: harness, signed in, then install.sh. The check is stated in the harness's own terms, start it once as that account and see whether it opens a session or asks you to log in, rather than duplicating an install route that belongs to another project and would go stale here.

Which harness is deliberately left open. dejima is growing support for more than one, and that set lives and changes there, so this page states the shape of the requirement and names Claude Code only as the worked example of where a state directory and a credential live. A list here that had to be kept level with dejima's would be the copied-contract problem this repository argues against everywhere else, and it would go stale in the direction that tells somebody their working setup is missing.

bin/dejima-devbox-bootstrap says it too, because its closing output is where the step gets skipped: that text hands over to install.sh and implied that was the last thing between the operator and a session. It keeps a check, since the failure is real and nothing else points at it, but the table it reads from is recognition rather than a statement of support, and there are three outcomes rather than two: found and signed in, found and not signed in, and nothing recognised, which is reported as something this program cannot see rather than as a step the operator failed to take, followed by the requirement in harness-neutral terms. That is the same reasoning that gives the audit its INDETERMINATE. It checks and does not fix, because the sign-in belongs to the account and writes a credential this program has no business handling.

The README's Use section carries the short version for the same reason it lists the other two commands.

Tested with bats test/: 99 passing, including a new handoff assertion in clone.bats alongside the existing one for install.sh, asserting both that the prerequisite is stated and that an unrecognised harness is not treated as a finding. The three bootstrap branches were exercised against a stub home for each state; shellcheck reports nothing new on the file.

Worth knowing for the parallel effort: bin/dejima-devbox-audit's radius report already stats ~/.claude/.credentials.json by name, on main and unrelated to this branch. Nothing here widens that, but it is the other place the same assumption is written down.

**Summary generated by LLM agent** Stacked on `ntfy-runbook` (#12), because it edits the same part of §5. Review that one first; the base becomes `main` once it merges. Neither runbook says that the account launching dejima needs a harness installed on the VM and already signed in before the first session. Bootstrap does not do it, `install.sh` does not do it, and the README's Use section lists exactly those two commands, which reads as the whole of the setup. Both halves of the prerequisite fail by pointing somewhere else. Signed in matters because the credential proxy runs host-side: it reads that account's copy of the credential and hands the container a placeholder, so an account that never signed in leaves it holding nothing and every session fails at the backend with the container looking like the broken part. Installed and run matters because the harness's state directory is a host path that has to exist on this side first, and a bind mount whose source is missing is either created as an empty root-owned directory or refused outright depending on how it is declared. Neither of those says "the harness has never run on this account", and the first leaves root-owned directories in a home that is not root's. So §5 gains a subsection that leads with the prerequisite, states what each half breaks, and gives the order it implies: harness, signed in, then `install.sh`. The check is stated in the harness's own terms, start it once as that account and see whether it opens a session or asks you to log in, rather than duplicating an install route that belongs to another project and would go stale here. **Which harness is deliberately left open.** dejima is growing support for more than one, and that set lives and changes there, so this page states the shape of the requirement and names Claude Code only as the worked example of where a state directory and a credential live. A list here that had to be kept level with dejima's would be the copied-contract problem this repository argues against everywhere else, and it would go stale in the direction that tells somebody their working setup is missing. `bin/dejima-devbox-bootstrap` says it too, because its closing output is where the step gets skipped: that text hands over to `install.sh` and implied that was the last thing between the operator and a session. It keeps a check, since the failure is real and nothing else points at it, but the table it reads from is recognition rather than a statement of support, and there are three outcomes rather than two: found and signed in, found and not signed in, and nothing recognised, which is reported as something this program cannot see rather than as a step the operator failed to take, followed by the requirement in harness-neutral terms. That is the same reasoning that gives the audit its INDETERMINATE. It checks and does not fix, because the sign-in belongs to the account and writes a credential this program has no business handling. The README's Use section carries the short version for the same reason it lists the other two commands. Tested with `bats test/`: 99 passing, including a new handoff assertion in `clone.bats` alongside the existing one for `install.sh`, asserting both that the prerequisite is stated and that an unrecognised harness is not treated as a finding. The three bootstrap branches were exercised against a stub home for each state; shellcheck reports nothing new on the file. Worth knowing for the parallel effort: `bin/dejima-devbox-audit`'s radius report already stats `~/.claude/.credentials.json` by name, on `main` and unrelated to this branch. Nothing here widens that, but it is the other place the same assumption is written down.

dejima-agent referenced this pull request

2026-08-17 15:40:01 -07:00

Generalise the audit's credential inventory once dejima supports other harnesses #14

branderson changed target branch from ntfy-runbook to main

2026-08-17 18:38:41 -07:00

branderson added 3 commits 2026-08-17 18:38:41 -07:00

Say that the harness is installed and signed in here, before dejima runs

tests / runner-env (pull_request_target) Successful in 35s

Details

tests / tests (pull_request_target) Successful in 54s

Details

54085211c6

Neither runbook said the account launching dejima needs a harness installed on
this VM and already signed in, and both halves fail in a way that points
somewhere else.

Signed in: the credential proxy runs host-side, reads this account's
~/.claude/.credentials.json and hands the container a placeholder. An account
that never signed in leaves it holding nothing, so sessions fail at the API and
the container is what looks broken.

Installed and run: the mounts under ~/.claude are host paths that have to exist
on this side first. A missing bind source is created as an empty root-owned
directory or refused outright depending on how it is declared, and neither of
those says the harness has never run here - the first quietly puts root-owned
directories in a home that is not root's.

So §5 now leads with the prerequisite and the order it implies, and states the
check in the harness's own terms - start it once as that account and see whether
it opens a session or asks you to log in - rather than duplicating an install
route that belongs to that project. The README's Use section carries the short
version, since it lists bootstrap and install.sh and until now implied those
were the whole of it.

Say the harness step where the operator is standing when they skip it

tests / runner-env (pull_request_target) Successful in 34s

Details

tests / tests (pull_request_target) Successful in 54s

Details

903983d63f

The runbook now states the prerequisite, and bootstrap's closing output is
where it gets ignored: that text hands over to install.sh and, until now,
implied that was the last thing between the operator and a session.

So it reports the harness alongside the audit result, and reports it three
ways, because one message for every state is how a check stops being read. No
~/.claude and the harness has never run as that account, which matters beyond
the credential: dejima mounts paths under that directory, and a bind mount
whose source is missing is a root-owned empty directory in somebody's home
rather than an error naming what is absent. The directory but no
.credentials.json and it has never signed in here, which is the state that
fails at the API with the container looking like the broken part, so the API
key route is named there too. Both present and it says what it actually knows,
which is that a file exists rather than that a token works.

It checks and does not fix. The sign-in belongs to the account and writes a
credential this program has no business handling, and §7 of the runbook is the
argument for keeping root's hands off it.

Check for a harness without deciding which one dejima runs

tests / runner-env (pull_request_target) Successful in 35s

Details

tests / tests (pull_request_target) Successful in 55s

Details

51024cb70a

dejima is growing support for more than one, and both halves of this were
written as though Claude Code were the only answer: the runbook named ~/.claude
as the state directory and .credentials.json as the credential, and bootstrap
tested those two paths and reported their absence as a step the operator had
skipped.

The requirement generalises even though the paths do not. A harness installed
for the account, run once so its state directory exists to be mounted, and
signed in so the host-side proxy has something to hold: that shape is the same
whichever harness it is, and it is what the runbook now states. Claude Code
stays as the worked example of where those two live, marked as an example, with
the set of supported harnesses left where it belongs.

Bootstrap keeps a check, because the failure it catches is real and arrives with
nothing else pointing at it. What changes is the table it reads from and the
verdict when nothing matches. The table is recognition rather than a statement
of support, so a harness missing from it produces "this cannot see one", which
is not a finding, followed by the requirement in harness-neutral terms. Three
outcomes rather than two, on the same reasoning that gives the audit its
INDETERMINATE: a check that reports a failure it cannot distinguish from its own
ignorance is worse than no check, because the operator either believes it or
stops reading it.

A copied list of what dejima supports would have been the other option. It is
the contract-kept-here problem this repository argues against everywhere else,
and it goes stale in the direction that tells somebody their working setup is
missing.

branderson approved these changes 2026-08-17 18:43:21 -07:00

branderson merged commit 6fadacb3bf into main

2026-08-17 18:43:27 -07:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima-devbox-hardener#13