`. A CLI emitting one per write grew the transcript without a ceiling for the run's 10-minute TTL. **Status.** Current ### Q2.208 — Why did the login wizard not run on macOS at all? **Rule.** BSD `script` reads its *own* stdin's termios to copy onto the new pty, so a pipe there kills the run before the agent is reached. `loginStdio` spawns a non-interactive flow with `/dev/null` on stdin on BSD; **Linux keeps its pipe unconditionally**, because util-linux `script` works with one today, an immediate stdin EOF is a plausible way for it to end the session, and Linux is where this deploys. **Why.** `LocalRuntime.login` spawned `script` with `stdio: ["pipe", "pipe", "pipe"]`, so it exited 1 with `script: tcgetattr/ioctl: Operation not supported on socket` — identical on claude, so the defect was pre-existing and not codex's, and invisible because Linux is where this deploys and util-linux's `-qec` form does not ask. `/dev/null` fixes kimi and codex; claude's flow needs the pipe that is the problem, so what changed for claude is that the failure is a sentence — `ui/login.ts` recognises that exact string and says "paste a token instead" — rather than a `tcgetattr` line in a `

**Measured.** Found 2026-08-07 while verifying codex's login and reproduced
outside the daemon. Confirmed on macOS 2026-08-08, both halves in one run:
`POST /agent-auth/kimi/login` exited 0 with `Logged in to managed:kimi-code.`,
and `POST /agent-auth/claude/login` exited 1 with the `tcgetattr` line, from the
same daemon. Still unverified is whether BSD `script` survives a full 15-minute
device flow with `/dev/null` on stdin — the run that proved the spawn works was
against an already-signed-in kimi, so it finished immediately. Q7.63.

**Rejected.** Taking the pipe away unconditionally, which would fix two agents by
breaking the third.

**Status.** Known limitation

### Q2.209 — Does `available: true` mean an agent can start a session?

**Rule.** No. `available` only ever meant "on PATH", and the login probe parses
`claude auth status`'s JSON rather than its exit code.

**Why.** A logged-out agent reported `available: true` and the person found out
at `502 agent_auth_required`, after a worktree had already been made. The exit
code does track the answer — `claude auth status` exits 1 when logged out — but
exit 1 is then indistinguishable from a crash or a missing binary, so it cannot
be the thing that is read.

**Status.** Current

### Q2.210 — What happens if the wrong `script` form is used?

**Behaviour.** Nothing loud. util-linux takes a shell string after `-qec`; BSD
takes argv after the typescript file; the BSD form on Linux writes a file called
`claude` and records nothing.

**Measured.** `claude auth login` prints the URL wrapped in an OSC 8 hyperlink
and waits on a paste prompt, so it needs the input box and **no inbound port**;
`kimi login` and `codex login --device-auth` are device-code flows and their
input box is never used. A lone `\r` becomes a newline — it means "redraw this
line", and dropping it concatenates every spinner frame into one.

**Status.** Current

### Q2.211 — What answers input posted to a login run that has no stdin?

**Rule.** `POST /agent-auth/login/:id/input` answers `400
login_not_interactive`.

**Why.** It was a silent no-op, which on the one screen where a device code is
typed once reads as a client that sent the code successfully. Whether a run has a
stdin pipe at all is decided by `AGENT_LOGIN[agent].interactiveStdin`, the same
field that decides whether the client draws the box — which is why it is in the
table rather than in either reader.

**Status.** Current

### Q2.100 — How many sessions may be running at once?

**Rule.** Two bounds, kept apart: **64 live**, and **16 creations then one per two
minutes**. Both answer `429`, and the refusal is made *before* the cwd is resolved,
so it costs no filesystem probe. **A resume is never refused by either** — putting
an agent back in front of an existing conversation is not manufacturing a session,
and telling somebody who has just typed that their own conversation is unavailable
is worse than being briefly over a soft ceiling. They are in memory;
`REEMOAT_MAX_LIVE_SESSIONS` and its siblings move them.

⚠ **What the live ceiling *means* changed with parking (Q2.224), and the number did
not.** It counts sessions holding an agent, which used only to be bounded from one
end — `create()` refused past it and nothing ever released anything — so it read as
"how many conversations you may have open" and was never a memory bound at all: at
the ~397 MB a live session was measured to cost, 64 of them is ~25 GB. Since the
daemon lets an idle agent go, the population it counts is bounded from both ends,
and what it caps is **agents resident at once** rather than conversations somebody
may have. The enforcement moved with the meaning: crossing the
ceiling — by waking a conversation or by creating one — releases the least recently
used *idle* session first, so the bound is kept by eviction rather than by refusal.
The two ends differ only in the last resort: a wake proceeds anyway, a `create`
answers `429`, and it does so only when every live session is mid-turn or waiting
on a person.

**Why.** `create()` had no bound of any kind, and the only thing counting sessions
anywhere was the startup prune — which counts in order to **delete**, keeping the
newest 200 by creation and taking every other transcript with it at the next boot
(only inactive rows now, and never under fifty — Q2.222 — but still a deletion). So the sole
consequence of creating sessions without limit was that somebody else's
conversations disappeared. `sqlite.ts`'s own comment beside that cap had already
written the precondition down — *"with one person there is nobody to take it
from"* — and a grant is exactly what makes that false. Both bounds are needed
rather than one: the ceiling bounds what is *running*, while the burst bounds
create-and-stop, which never touches the ceiling and still writes every row the
prune later deletes.

**Status.** Current

### Q2.101 — What bounds an agent's stderr before there is an event to bound?

**Rule.** 64 KiB per line without a newline, flushed as its own line past that.

**Why.** The accumulator in `pumpStderr` had no ceiling, and every bound downstream
of it is on the *event* — which does not exist until a line does. An agent writing
without a newline therefore grew a string that nothing in the system measured, past
the per-event cap, past the per-session byte budget and past the queue's own byte
ceiling, none of which had anything to charge.

**Status.** Current

### Q2.102 — What happens when two consumers want the same event queue?

**Rule.** Ownership of `EventQueue` is a checked monotonic claim rather than an
assumption. Taking a claim wakes the previous holder with `null`, and `next()`
answers `null` for a claim that is no longer current, so a reader already resumed
cannot take one more event on its way out. A turn outranks a drain — `claimForIdle`
refuses while a turn holds it — and **nothing displaces a turn**: `claimForTurn`
refuses rather than displacing. `release` is identity-checked.

**Why.** `next()` used to park its resolver in `waiting` unconditionally, so a
second consumer silently overwrote the first and the displaced one never settled —
a **hang** rather than a mismatch, and a hang inside `harness` or the Session-level
drivers. The asymmetry is not tidiness: a `claimForTurn` that displaced instead of
refusing can strand the hold with no owner able to clear it, which silently returns
the session to buffering — the very state the idle drain exists to end. And a stale
`release` under a live turn would route that turn's events to the drain, park its
generator and pin `ManagedSession.turn`, i.e. `409 turn_in_flight` for the rest of
the session's life.

**Status.** Current

### Q2.103 — Can a cancel arrive before the prompt it is meant to stop?

**Rule.** Yes, and it is honoured rather than overtaken. `pump` tests the cancel
marker *after* reading a prompt's attachments and writes its own
`turn_end{cancelled}`.

**Why.** `prompt()` sets `turn` synchronously, but `Session.turnActive` is not set
until `pump` first pulls the generator — and reading an inlined image's bytes is a
real `readFile` between the two. A cancel landing in that window reaches an agent
holding no prompt, which every adapter discards, and the loop would then send the
message anyway: the turn somebody stopped runs to completion. The daemon writes the
`turn_end` itself because the agent never gets to send one, and a prompt with no
turn end at all is the shape this codebase calls a message that reached no model.

**Status.** Current

### Q2.104 — What does `Session.EventQueue`'s 2000-event bound still protect?

**Decision.** 2000 events, evicting only `agent_log` and `other`, and never
drop-oldest — dropping `text` or `file_change` yields a contiguous log that is
missing content. What it *bounds* is now narrow: the gap between `adopt` and
`onStarted`, plus any bare `Session` — `harness`, the Session-level drivers — where
nothing drains between turns at all.

**Why.** With `ManagedSession.startIdleDrain` attaching a reader between turns, the
thing this cap used to bound is no longer reachable through a managed session: the
agent talking after its turn ended is drained rather than buffered. The number is
kept rather than lowered because the two remaining windows are real, and kept rather
than raised because the eviction policy — not the size — is what makes an overflow
survivable.

**Measured.** Before the drain: 57 events held for 295 s on one session, with
content past 2000 silently evicted through the head placeholder. Q2.44.

**Status.** Current

### Q2.105 — Why does the registry still append permission events now that the queue drains between turns?

**Decision.** The rule is unchanged — the registry appends permission events, not
`session.ts` — and its reason is not.

**Why.** The reason recorded at Q5.57 was that `Session`'s `EventQueue` drains only
while a prompt generator is being consumed, so an event pushed there outside a turn
is stranded. A `ManagedSession` no longer permits that, so the old argument has
lapsed. What replaces it is stronger: `settle()` appends **synchronously**, in the
statement after the agent's own promise is resolved, so routing a
`permission_request` through the queue would put a microtask between the two — and a
client answering inside that microtask could beat its own request into the log.

**Status.** Current — supersedes the reasoning given at Q5.57, which the drain made
obsolete.

### Q2.106 — Does codex resume a conversation end to end, or only advertise that it can?

**Behaviour.** End to end. `codex-acp` 1.1.9 advertises `sessionCapabilities.resume`
— which `AcpClient.supportsSessionResume` reads — and it was measured under the
daemon rather than only off the handshake: a session restarted by the daemon
answered a question about its own earlier turn.

**Why it is recorded.** The claim "all three agents implement `session/resume`" is
what `autoResumable` and the whole boot pass rest on, and Q2.1's measurement covers
claude and kimi only. Advertising a capability and honouring it are different facts
here — the same distinction kimi's plan-mode `-32603` makes (Q2.8) — so the third
agent's is written down separately.

**Status.** Current

### Q2.107 — Code arrives as an archive. Where does the containment argument come from?

**Question.** `POST /fs/import` takes a `.zip` or `.tar.gz` and unpacks it into a
directory somebody picked. Every other path in this daemon deals in paths a person
chose out of a listing of what already exists. An archive member is a string a
remote party wrote, used to create a file. What authorises the write?

**Decision.** Nothing does, and that is the point — the argument is **refusal
first, and it is purely syntactic**.

`paths.ts` already says this in as many words: `atOrUnder` "is correct only where
the path is ours and merely not created yet, and nothing may use it to authorise
an action on a path somebody else chose." `atOrUnderReal` — the primitive that
would have been reached for here — was deleted with its last caller rather than
kept, precisely so that a future caller would have to make this argument instead of
inheriting one.

So `safeMemberPath` is pure, touches no filesystem, and runs before anything is
created. It refuses NUL and control characters, a backslash (a member path is POSIX
or it is refused, never translated), a leading `/` or a drive prefix, any `..`
segment, `.git`, and anything past a depth or length bound. **Both readers go
through it**, which is what stops zip and tar drifting into disagreeing about what
is safe — the failure that would otherwise be found one format at a time.

**`..` is refused rather than normalised**, and that is the whole of the zip-slip
answer. A member reading `a/../../x` is not asking for `x`, it is probing for
whether this code normalises; every surviving zip-slip works by the check running
on the pretty form and the write running on the raw one. There is no pretty form.

**The filesystem half adds exactly one thing: `O_EXCL`.** Every member is written
`"wx"`, the flag `Uploads.receive` already uses, which never follows a link and
never truncates. A link planted between the check and the write is an `EEXIST`.

**Measured.** `daemoncheck` builds both formats itself — shelling out would not
have worked, since GNU tar refuses to *write* a `../` member at all, which is
exactly the member worth being sure about. Every refusal is asserted in a pair: the
refusal, and that nothing at all was created, staging directory included.

**Status.** Current

### Q2.108 — Why is a `.git` inside an archive refused, when cloning a hostile repository is accepted?

**Question.** `CLAUDE.md` is explicit that git hooks run as you and that this is
the intent: "Cloning a hostile repository is exactly as dangerous here as in your
own terminal — and no more." An imported `.git` is the same bytes. Why treat it
differently?

**Decision.** Refused, because the sentence above has a clause that does not
survive the move: *in your own terminal*. The danger there is one you initiated and
are watching.

The daemon runs `git worktree add` on the directory somebody picks, and `git.ts`
deletes `GIT_NO_EXEC_CONFIG` on purpose so that a repository's own `post-checkout`
and its LFS smudge filters run. For a repository you cloned, that is correct and
was measured — neutralising it checked out LFS pointer files instead of content.
For an imported one it makes "upload a file" mean "the daemon executes what was in
that file", with no agent in between and nobody on screen. Every other route to
executing a hostile repository in this system goes through the agent, which is the
thing a person is watching.

**Nothing legitimate is lost**, which is what makes this cheap rather than a trade:
the export skill excludes `.git` anyway, and somebody who wants history asks the
agent to clone — the existing path, on screen while it happens.

**Rejected.** Allowing it and stripping `hooks/`. That is a second, weaker rule
about the same directory, and `.git/config` still carries `credential.helper` and
`core.sshCommand`.

**Reversible, and deliberately so.** It is one clause in `safeMemberPath`, and
`webcheck` pins the export skill against it so the two cannot come to disagree —
a skill that packed a `.git` would produce an archive refused *whole*, and the only
symptom would be a 400 at the end of the slowest step somebody takes.

**Status.** Current

### Q2.109 — An import writes into a directory the daemon does not own. What may it not do to it?

**Question.** This is the only route that creates files inside a folder somebody
else made. What happens when it fails halfway?

**Decision.** Nothing in the target is touched until one `rename`. Extraction goes
to `/.reemoat-import-/tree/`, so a failure at any point leaves the
folder exactly as it was.

**Staging sits inside the target rather than beside the worktree and upload roots**,
for two reasons that are both requirements rather than preferences. The `rename` is
then within one filesystem by construction, where a root under `~/.reemoat` would
be an `EXDEV` copy for anybody whose projects live on another volume. And a third
remover tree would owe `scripts/daemon.ts` a proof that it nests with neither of
the other two (Q5.74) — a startup refusal that is currently a two-way check.

It also buys the thing that makes the rest of the file ordinary: **because the
daemon created the staging directory, every path below it is one it made**, so the
rule about bounding filesystem calls through `stall.ts` — which is about paths
somebody else named — does not apply below that line. `resolveCwd` on the target is
the bounded half.

**The destination is `lstat`ed before the rename, and anything there at all is
refused.** Measured on macOS: `rename(2)` answers `ENOTDIR` for a destination that
is a file or a symlink, `ENOTEMPTY` for a non-empty directory, and **succeeds for
an empty one** — implicitly `rmdir`ing it. That loses no data and is still a
removal of a directory this daemon did not create, which is exactly what it may not
decide to do. The errno mapping below the check is the backstop for the race, not
the rule.

**Known limitation.** A daemon restart mid-import leaves a `.reemoat-import-*`
directory behind. It is dot-prefixed so the picker hides it and named
unmistakably; sweeping directories the daemon does not own would be worse than the
defect.

**Status.** Current

### Q2.110 — Two archive formats. What did each actually cost?

**Question.** Zip is what Finder's Compress and Windows' "Send to" produce; tar.gz
is what the export skill writes and is the better archive. Accepting both means two
readers. What was not obvious?

**Decision.** Both, chosen by **magic bytes rather than by filename** — a filename
is the least reliable thing in the request. Five things cost a measurement:

**A zip states every member twice and the copies may disagree.** Only the central
directory is read. Every extractor ever walked past a check was walked past it by
validating one copy and reading the other; the local header is consulted for
exactly one thing, its own name and extra lengths, being the only way to know where
the data starts.

**The zip64 extra field is positional.** Its members are present only when the
corresponding 32-bit field is saturated, always in the same order. Reading it at
fixed offsets yields a garbage offset out of a valid archive — the first draft did
this and it was caught by reading it back rather than by a test.

**A zip name without general-purpose bit 11 is CP437, and is refused.** Decoding it
as UTF-8 anyway turns undecodable bytes into U+FFFD and collapses distinct names
onto one — a check passing on one string while a file is created at another. Pure
ASCII is identical in both, so only a genuinely ambiguous name is refused.

**pax headers are read, not refused.** macOS ships bsdtar, which writes typeflag
`x` ahead of members whose metadata does not fit the 1979 layout, routinely rather
than rarely. Refusing them refuses most archives made on a Mac.

**`__MACOSX/` is skipped.** Finder writes a parallel resource-fork tree beside the
folder it compressed, so *every* zip made that way has two top-level directories —
which would fail the single-root rule and refuse the most likely archive there is.

**And one that is about Node rather than about archives.**
`handle.createReadStream` per member registers a `close` listener on the shared
`FileHandle` and releases none until the import ends, so a zip of twenty thousand
members registers twenty thousand. Node warns at eleven, which is how it was found
— from `daemoncheck`'s output, on an archive of eleven files. `readRange` reads
positionally and has no such bookkeeping.

**Status.** Current

### Q2.212 — A plugin child is not detached and nothing reaps it. Why is that not the gap it looks like?

**Decision.** A plugin's child process is spawned **without** `detached`, no pid
is recorded, and there is no reaper. `runner.ts` exits when its IPC channel
closes, and that is the whole of plugin cleanup.

**Why it is the opposite of an agent's.** An agent is spawned `detached` because
`claude-agent-acp` runs the CLI as its own child and cleans up only on
`process.on("exit")`, which does not run under SIGKILL — so the process *group* is
the only thing that can be killed reliably. That is why `sessions` has a pid
column, why the reaper exists and why it is fenced by `os.uptime()`: a pid
recorded before a reboot names somebody else's process afterwards.

A plugin has none of those problems. It spawns nothing, holds no conversation, and
its channel dies with the daemon — gracefully or not. A daemon that crashes leaves
children whose `disconnect` fires, and they go. The next daemon start spawns fresh
ones from the rows.

**What this means for a change.** If a plugin ever needs to outlive the daemon —
it should not — the pid column, the fence and the reaper all come back with it,
and this entry is where the argument for the current shape is.

**Status.** Current

### Q2.213 — What may a failed install destroy, and when?

**Question.** `PluginHost.install` publishes the new tree, writes the row, starts
the child, and then removes what it replaced. Its catch is supposed to put
everything back. Which of the two orders is load-bearing — the order things are
committed in, or the order they are destroyed in?

**Rule.** The way back is destroyed **last**: after every statement that can
throw, and after the plugin being replaced is certainly stopped. The commit point
stays where it is.

**Why the reinstall path is the only one that matters here.** The target path
carries the version, so on a version-changing update nothing is moved aside at
all — the new tree goes to a directory that does not exist yet. A plugin is moved
aside on exactly one path: reinstalling the version already installed, which is
the documented way somebody iterates on a plugin they are writing. So this is not
a rare window in a rare path; it is the only path on which the machinery runs.

**What went wrong.** The old tree was discarded immediately after the row was
written, with three fallible statements still to come — the second discard,
seeding the new plugin with the sessions this daemon already has, and the second
stop of the incumbent. On the reinstall path the thing discarded *is* the running
plugin's directory and the newly published tree is the same path, so a throw ran a
catch that removed the new tree and found the old one already gone. Both trees
lost, the row naming a directory that is not there, and the plugin permanently
failed on a budget spent against a missing file. The catch's own order — remove
the new tree, then rename the old one back — was always right; it simply had
nothing left to put back.

**A second reason, independent of any throw.** The incumbent can come back
through the hook queue's drain between the first stop and the swap, which the code
above that stop already explains. If it did, it is executing out of the directory
that was renamed aside — and deleting that from under a live child is its own
defect. Hence *after* the stop specifically, rather than merely later.

**Rejected.** Moving the row write below the cleanup. The filesystem and the row
part company earlier than that, when the incumbent's tree is renamed out from
under a row still naming it, so this moves the window rather than closing it — and
it costs the flag the catch reads in two places to know whether it must restore.
The row write is the commit point and it is correctly placed; the defect was in
the order of destruction.

**And the data.** The same catch removed the row of a failed *first* install
without dropping that plugin's stored keys, which `doRemove` never does — it pairs
the two and says why. Unpaired here is permanent: afterwards there is neither a
row nor a directory, so an uninstall answers 404 and `dropPlugin` can never be
reached again. The keys then reappear under the next install of that id, because
plugin data is keyed by id rather than by version — deliberately, so that an
update keeps it. Safe to drop for the reason that same comment gives from the
other side: a first install that failed is not an update, and before it there was
no data of that id to keep.

**Deliberately still open.** A hard crash between the two renames leaves the same
divergence, and no in-process ordering closes that. Reconciling it at open — a
missing version directory beside exactly one directory this daemon moved aside —
is a separate change with a separate justification (power loss, not logic), and it
should not ship without a driver that can walk it: a recovery path nothing
exercises runs for the first time exactly when everything is already wrong.

**Status.** Current

### Q2.214 — Prose was clipped so a person would not be shown a wall of text. What did that cost?

**Decision.** The three character caps on an elicitation's prose are gone —
`MAX_ELICITATION_MESSAGE_CHARS` (512), `MAX_ELICITATION_TITLE_CHARS` (100) and
`MAX_ELICITATION_DESCRIPTION_CHARS` (300). `message`, a field's `title` and
`description`, and an option's `label` and `description` are carried exactly as the
agent sent them. `MAX_ELICITATION_FORM_BYTES` — 32 KiB over the projected form — is
the only bound left, and it **refuses** rather than shortening.

**Why. Because that is where the question lives.** `askTitle` reads a step's
heading from the field's `description` first, the form's `message` second and the
field's `title` last, and the order is not arbitrary: with several questions on one
form the adapter puts each *question* in its field's description and leaves
`message` as a preamble. So `MAX_ELICITATION_DESCRIPTION_CHARS` was a 300-character
cap on the sentence somebody is being asked to answer, and on the sentence
explaining what each answer means. The asymmetry Q2.23 argued — *structure is
refused because a form missing a question means something different* — applies word
for word to a question missing its second half.

**Measured 2026-08-24 against `~/.reemoat/reemoat.db`.** Over every
`AskUserQuestion` in the log: questions 26 median and **155** longest, option labels
29 median and **48** longest, option descriptions 139 median and **318** longest.
One of fifteen option descriptions was over the cap and was being cut on screen —
not a pathological case, an ordinary one, and the caps sat close enough to real
values that the next one along would go too.

**Why a byte backstop is enough, where three character caps were not.** The form
does **not** ride `SessionSnapshot` (Q2.24) — it is fetched by
`GET /sessions/:id/elicitations/:id` when a card opens — so the thing being bounded
is one response to one request, not sixty rows every four seconds. 32 KiB was
already the number for that, already a refusal, and already named in its own
message. What it did not have was an assertion against a *single* enormous string,
which the per-item caps used to catch; `daemoncheck` now drives both shapes.

**What was kept.** Every refusal: 24 fields, 24 options, an option `value` over 512
characters, an unknown property type, a list with no choices. A `value`
round-trips to the agent verbatim, so a clipped one is an answer it cannot
recognise — that argument is untouched and is why the split now runs between
*structure* and *prose* rather than between refusing and clipping.

**And the same measurement, one channel over.** `MAX_PERMISSION_TITLE_CHARS` and
`MAX_PERMISSION_OPTION_NAME_CHARS` went with them, replaced by
`MAX_PERMISSION_SNAPSHOT_BYTES` — 8 KiB over `{title, options}`, refused. Those two
*do* ride the snapshot, which is why they were bounded at all (Q7.82), but the
amplifier was never the string length: it was the pair being re-sent for sixty
sessions every four seconds, and one whole-object number says that where two
per-string ones only approximated it. Clipping `option.name` also had a cost nobody
had noticed: kimi's `AskUserQuestion` arrives down the permission channel, so that
name is a model-written *answer*, and `askedQuestion` recovers the question by
matching it against the same string in `rawInput` **by identity** — `rawInput` is
bounded by bytes and never by characters, so past 200 the two sides disagreed and
the whole question fell back to a row of buttons. Measured maxima on the same log:
title **14**, option name **31**.

**Status.** Reversed an earlier decision

### Q2.215 — An assembled session that had never been prompted came back bare

**Rule.** One option bag for every launch. `ManagedSession.launchOptions` is a
private getter typed as `SessionOptions`, and all three launch sites read it:
`start()`, and both arms of `doResume`. A resume adds `agentSessionId` and nothing
else.

**What was wrong.** `doResume`'s empty-conversation arm wrote its bag out by hand and
left `...this.assembled` off it. So a session assembled as *Claude Code · Kimi K2*
came back on claude's own account and claude's default model, while
`sessions.custom_agent` and the snapshot went on naming the assembled agent — the
right name on screen and the wrong vendor on the bill.

**Why it was silent, which is the whole entry.** The invariant written to make
exactly this refuse — *routable and un-pinnable must refuse* — is enforced inside
`applySystem`, and `applySystem` returns at its first line when `options.system` is
absent, before `client.routing()`, before `hostable`. `spawnEnvOf` is the same shape:
no system, no `routedModelEnv`, `{}` returned, no variable set. An omission therefore
does not produce a *wrong* route for the guard to weigh; it produces **no route at
all**, which is the one input every check on this path is built to pass straight
through, because it is what every session started before assembled agents existed
looks like. `SystemRoutingError` cannot fire on a bag that asked for nothing. **This
is a guard bypassed by a door it does not sit on**, and no amount of hardening inside
`applySystem` would have reached it.

**The arm was ordinary, not an edge.** `conversationKnownEmpty()` answers `true` for
every session at `turnCounter === 0`, so *every created-but-unprompted session* took
it: a daemon restart, a tap on Resume, an ultracode toggle, `restartAgent`, and the
clear-then-resume path the arm was actually written for. A preset assembled and
started from the New session sheet is unprompted by construction until somebody
types, so this was the first launch of a routed session rather than a rare one.

**Why the bag was hoisted rather than the one arm patched.** The three sites were
compared field by field first: byte-identical apart from `agentSessionId`. Nothing is
per-arm, so a shared bag obscures nothing — it removes the only place an omission can
hide. It is typed `SessionOptions` rather than as an inline shape, so a field added to
that type is a compile error at one site instead of a silent omission at three. And it
stays a **getter**: `assembled` goes back to the preset store, `ultracodeWanted` folds
in the machine default and `elicitations` is a thunk, so a captured bag would
reintroduce exactly the staleness the resolver exists to prevent.

**What makes a fourth launch site loud: nothing does, and that is worth saying
plainly.** A fourth site calling `Session.start` with a literal of its own would be
exactly as silent as the third one was, because the silence is a property of a bag
with no system rather than of how many bags there are. What was bought is narrower.
There is now one expression of the bag, and `daemoncheck` drives a real
`ManagedSession` down **both** arms of `doResume` and asserts the two launches agree
on the agent, the spawn environment, whether `providers/set` was sent and the model
pin. A fourth site is caught only if something drives it.

**The driver's first attempt at that assertion was false coverage, and only the
revert discipline found it.** It compared the ACP `session/new` and `session/resume`
request params minus `sessionId`, and stayed **green** with the fix reverted: losing
the system and the model changes none of `cwd`, `mcpServers` or `_meta`. What it
changes is the spawn environment and whether `providers/set` was sent, and neither of
those is in the ACP request. An assertion that reads as covering the defect it cannot
see is worse than no assertion, because it is believed; it compares `shapeOf` now,
and the reason is written at the helper so it is not simplified back.

**Status.** Current

### Q2.216 — A preset re-pointed at another harness, under a session already on it

**Decision.** `ManagedSession.assembled` **compares** the harness and does not follow
it. The resolver answers `{harness, system, model}` now, and the getter returns `{}`
when `one.harness !== this.agent` — the same demotion the deleted-preset arm one line
above takes, for the same reason: the preset has stopped describing this session, and
the honest answer is the bare harness `sessions.agent` has named all along. The
harness travels out of the store to be compared and is used for nothing else.

**Why nothing anticipated it, which is the useful half.** Q7.116 chose a *reference*
over a copy precisely so that "editing a preset changes what its sessions come back
as", and Q3.493 built the edit that makes the reference worth its cost. Both were
reasoning about a **model** change — the same CLI, a different model, resolved at the
next launch, which is what somebody expects of a preset. But `PATCH
/custom-agents/:id` is a *replace*, for the reasons Q3.493 gives, so all four fields
move and the harness is one of them. The reference was bought for a change of model
and delivered a change of vendor.

**Two repros, and the quiet one is worse.** Preset `{claude, anthropic, opus}` edited
to `{codex, openai, gpt-5-codex}` left a claude session resuming with
`system: "openai"`, whose `nativeHarness` is codex, so `applySystem` reached
`hostable` and every resume from then on answered `502 system_not_routable` —
permanent, and connected to the edit by nothing on any screen. Edited instead to
`{kimi, moonshot, kimi-k2-thinking}` it left the **claude** harness routed at Moonshot
on that model: a triple `hostable` permits, that `POST /sessions` could never have
produced, that starts and runs and bills somebody's Moonshot key, under a tile saying
Kimi Code.

**Why a demotion and not a refusal at the route.** `sessions.agent` is immutable
because the agent *process* is spawned from it, and the transcript, the resume id and
the credential on the other side all belong to that CLI. So a session whose preset has
changed harness has exactly two honest outcomes — the bare harness, or a refusal that
never expires — and the deleted-preset arm had already chosen the first. A refusal at
`PATCH` would also be the wrong shape: it lets a sleeping session veto an edit to a
list that is somebody's own scratchpad, on the machine they are looking at.

**Two comments asserted the opposite invariant and are corrected.**
`CreateSessionOptions.customAgent`'s said the harness and the preset's harness can
never disagree; it now says they agree *at creation* and names `PATCH` as the thing
that parts them. `readAssembledAgent`'s said the shared validator exists so that no
edit "puts the unstartable row into the store by the back door" — true of the row and
false of the sessions pointing at it, since `hostable` is weighed against the PATCH
**body**, which says nothing about a session that already exists. Its guarantee is
scoped to the store now, with `assembled` named as what keeps an existing session
startable. Prose arguing for what the code no longer does is the failure this
discipline exists to prevent, and both of these were one edit away from being it.

**A fact about driving it.** The quiet repro's resume **succeeds**. An assertion that
reads only the outcome stays green against the broken code; only one that reads the
launch *shape* — no system, no model, no routed variable in the spawn environment —
goes red. `daemoncheck` pins the shape, and pins the matching-harness case beside it,
because a guard that demoted every assembled session would pass every other assertion
in that section.

**What is still dishonest, and it is on screen rather than in the daemon.**
`SessionSnapshot.customAgent` is a join key, so a session that has degraded is drawn
under the preset's name, glyph and pairing regardless. This is Q7.120's gap reached
through a second door, and it is not closed by this.

**Status.** Current

### Q2.217 — A resumed session on a native pairing ran the agent's own default model

**Measured.** A real `Session` driven against a fake ACP peer publishing a
`category: "model"` select — `currentValue` sonnet, choices sonnet and opus — under
`{system: "anthropic", model: "opus"}`. `Session.start` sent
`session/set_config_option` on that option's own id carrying `opus`. The resume sent
**nothing at all**, and the conversation came back on sonnet while the tile, the
snapshot and `sessions.custom_agent` all went on naming the preset. That the resume
*had* the list to weigh the model against is not an inference either: the SDK's
`ResumeSessionResponse` carries the full `configOptions`, and `claude-agent-acp`
0.63.0's `getOrCreateSession` populates it, so `modelOption` is already there by the
time `adopt` returns. Nothing was missing but the call.

**Why it was silent, which is the half worth reading.** For a *native* pairing there
is no second door. `spawnEnvOf` answers `{}` — there is no `ROUTED_MODEL_ENV` for a
harness talking to its own vendor — and `applySystem` returns at its first line
because `SYSTEMS[system].nativeHarness` is the harness already running.
`session/set_config_option` is therefore the whole mechanism, and skipping it produces
**no wrong pin for any guard to weigh**: it produces no pin, which is what every
session started before assembled agents existed looks like and is the one input every
check on this path is built to wave through. **That is the second post-mortem this
week on a guard bypassed by a door it does not sit on**, and the first is Q2.215 —
same shape, one door along. Q2.215 lost the whole option bag at one of three launch
sites and was caught by hoisting the bag; this lost the one half of it that is applied
by a *call* rather than by an environment variable, at one of two launch sites, with
the bag entirely correct at both.

**The asymmetry that made it findable, and it is a fact rather than an aside.** Resume
accepted a triple create refuses. With the model gone from the agent's published list,
`Session.start` throws `SystemRoutingError` and `POST /sessions` answers `502
system_not_routable`; the resume of that identical pairing came back happily on
whatever the CLI defaults to. A pairing that cannot be created but can be resumed is
not a state anything here intended, and the two arms disagreeing is what said the pin
was on one path only.

**Decision.** The resume path pins when it can and reports when it cannot. Three
options were weighed and two of them are the two failures this file already records.
*Refusing on resume the way create refuses* strands a conversation for ever the first
time a CLI retires a model — a permanent 502 on a session that worked yesterday,
connected to nothing on any screen, which is exactly the stranding shape Q2.216
deliberately designed away days earlier when it chose a demotion over a refusal that
never expires. *Demoting silently* is the defect above, relocated. So neither: pin it
while the agent still offers it, and put a sentence in the transcript when it does
not.

**The mechanism is one this daemon already has, and that is deliberate.**
`pinNativeModel` **answers** the refusal sentence rather than throwing it
(`Promise`), because its two callers disagree about what an un-pinnable
model means and only the *reaction* is theirs — the wording stays in one place.
`Session.start` wraps the answer in `SystemRoutingError` inside the dispose-and-rethrow
it already had, so the start path is byte-for-byte what it was, 502 included.
`Session.openResumed` resumes anyway and pushes one `error` event onto the session's
own queue, naming the model that was asked for and the one the session is running,
with `data.code` of `model_not_pinned`. No new event type, no wire field and no
`registry.ts` change: `error` is the event this daemon already writes about *itself*
when it carries on after something it could not do — `abandonResume` is the same shape
— it is already drawn by `EventList`, already sized and truncated in `events.ts`, and
the registry's `startIdleDrain` already records it, which is the channel
`session_started` reaches the log by.

**`error` rather than `onWarning`, and the precedent is the point.** `onWarning`
reaches whoever is reading the daemon's stdout; the person this concerns is holding a
phone. It is the loud red row on purpose, because the alternative that was actually
considered was refusing the resume outright. And a `set_config_option` the agent
*rejects* on a resume is announced the same way rather than thrown — `restoreConfig`
already swallows exactly this failure, for exactly this reason, since a live
conversation is not torn down over a config option; what is new is that this one is
not swallowed silently. On start that call still throws, unchanged.

**How it has to be driven, because the resume succeeds either way.** The sweep is
{start, resume} × {native, routed} × {model offered, model gone}, and the assertion
reads the calls made on the wire rather than the outcome — Q2.215's false-coverage
lesson and Q2.216's quiet repro for the third time. Native/offered on the resume arm
is the defect's own cell; native/gone on the resume arm asserts the resume did *not*
throw and that the log carries exactly **one** notice, counted rather than merely
present, so a second launch may not append a second copy; start/gone stays a 502 with
the client disposed, and a driver asserting only one of that pair records nothing
about the asymmetry that is the decision. The mutations that must turn a cell red are
`pinNativeModel` answering `null` unconditionally and the pin deleted from
`openResumed`; both left every pre-existing assertion in that section green. The rig's
fake peer had to publish a model select on **both** responses before any native cell
was reachable at all — until then every native pairing took the `modelOption === null`
arm, which is why the sweep could be written and still see nothing.

**What it costs, and neither cost is closed here.** One notice per resume: a session
whose model has been retired and that is resumed after every daemon restart accrues a
row each time. That is honest and matches `abandonResume`'s per-give-up shape, and if
it proves noisy the fix is a dedupe against the last such event, never a demotion back
to silence. And `SessionSnapshot.customAgent` is still a join key, so a session that
has just been announced as demoted is still *drawn* under the preset's name, glyph and
pairing — Q7.120 and Q2.216's own remaining dishonesty, reached through a third door.
The transcript now disagrees with the chip out loud instead of silently, which is not
the same thing as closing it.

**Status.** Current

### Q2.219 — An OpenRouter session offering OpenCode Zen models

**Question.** Reported twice. Q3.519 divided opencode's one 362-row model control
into `OpenRouter` and `OpenCode Zen` headings, which is what "separate them" was
read as. The second report was sharper: *"if the session is through openrouter,
then the models there are openrouter's, zen is not needed."* A heading was never
the ask.

**Decision.** `narrowToSystem` filters the **snapshot's** model choices to the
session's own system, keyed on `nativeModelPrefix`. The log keeps everything the
agent published.

**Why it is a correctness fix and not tidying.** A session is a
harness × system × model triple, and the preset names it. Choosing a Zen model in
an OpenRouter session leaves the session running a model from a system its own
preset does not describe — while the chip, the tile and the glyph all go on saying
OpenRouter. That is Q2.216's dishonesty exactly, reached through the model menu
instead of through a preset edit, and unlike a preset edit there is nothing to
announce it.

**⚠ The namespace is the *pairing's*, never the current value's** — which is the
whole reason this is on the daemon rather than in the browser. The browser holds an
`AgentConfigOption` off a snapshot and knows nothing about systems: it could only
infer the namespace from whatever model is selected, and a session already switched
to the wrong system would then be offered **only** that system, for ever. The
daemon reads it through `assembled`, so a preset re-pointed at another harness
answers `null` here for the same reason it answers no system there.

**⚠ The selected choice is never removed, whatever namespace it is in.** A list
missing the value its control is set to makes `chipValue` fall back to a raw id and
makes `pinNativeModel` refuse the next resume with *"has no model called …"* — so a
session somebody had already switched by hand keeps a way back to itself instead of
being cut adrift by the fix.

**Narrow twice, and both exits are by identity.** `category === "model"` only,
since no other control's values are namespaced; and only where the system sets a
`nativeModelPrefix`, which is opencode's two and nothing else. Every other agent's
list is returned as the same object.

**Where it is not.** Not in `toConfigOptions`, which is a faithful ACP flattening,
and not in the log — the transcript records what the agent said. `snapshotConfig`
is the right seam and already shapes this payload for a stated reason:
`dedupeAliasChoices` removes a placeholder from it, and `withUltracode` adds a row.

**Known limitation.** `POST /sessions/:id/config` still *accepts* a model outside
the namespace; nothing offers one any more, but the route does not refuse it. The
guard belongs beside `pinNativeModel`'s own refusal and is not built.

**Status.** Current

### Q2.218 — Four prompts, three turn ends

**Question.** A session's log held four `prompt` events and three `turn_end`s. The
missing one belonged to a turn that ended in an `error` — a provider refusing the
model, surfaced verbatim. Is a turn that failed a turn that ended?

**Decision.** Yes, and `pump` writes the end itself:
`turn_end{stopReason: "agent_error"}`, immediately after the error and only when
the turn actually failed.

**Why.** The argument is Q2.103's, already made a hundred lines up in the same
file for the cancel path: the daemon writes the end because the agent never gets
to send one, and **a prompt with no turn end at all is the shape this codebase
calls a message that reached no model**. `Session.prompt` converts a rejected
`session/prompt` into an `error` event and returns on it exactly as it returns on
a `turn_end`, so the turn was over and nothing on the wire said so.

**What it cost, none of it a spinner.** Nothing was stuck — `pump`'s `finally`
clears `turn`, `showsWorking` reads the snapshot, Stop comes down and the composer
stays open. Three quieter things broke instead. `Tail.taskFloor` is raised by
`session_started` or a non-`end_turn` `turn_end` and by nothing else, so a turn
that failed **mid-delegation** left its pending calls counted for the rest of the
session under a permanent "waiting for 1 task" — the exact false line that floor
exists to prevent. The `turn.ended` plugin hook never fanned. And the turn's origin
claim was never spent, so a plugin that started the failed turn had the **next**
turn's hook suppressed instead — a bug that outlives the turn it came from.

**`agent_error` is a sixth reason, and none of ACP's five would do.**
`TurnEndEvent.stopReason` was ACP's closed union; it is `TurnStopReason` now.
`refusal` is the *model* declining and `cancelled` is something a person did, and
either would be a lie in the one row a reader trusts about what happened. The
client needs no change to accept it — `wire.ts` has always typed this field as
`string` and `stopReasonText` falls through to the identifier — which is this
wire's standing rule for an unknown value, exercised rather than assumed.

**⚠ And the predicate is not "an `error` was seen", which is where the first draft
was wrong.** The turn generator yields `CLOSED` — `{type: "error", message:
"session closed"}` — whenever the queue closes under it, which is this daemon
disposing the agent on a stop, a restart or a replacement. Writing `agent_error`
there would blame the agent for a teardown we performed, and fan a plugin hook on
a path no plugin has seen. `isSessionClosed` is exported from `session.ts` and
compares by **identity**: the message is prose, and matching it would make an
agent that happens to say "session closed" indistinguishable from us saying it.
`drainBetweenTurns` already recognised the sentinel; the turn loop did not.

**Rejected: drawing a row for it.** `showsInTranscript` answers `false` for
`agent_error` as it does for `end_turn`, and for the opposite reason — the row
immediately above is the agent's own error in the agent's own words, so a line
under it saying the turn ended states one fact twice, the second time worse. The
floor is raised regardless, because `taskFloor` runs before that gate: "nothing is
drawn for it" and "nothing happened" are different sentences and `webcheck` pins
both.

**Rejected: fixing `taskFloor` alone, client-side, with no wire change.** It is
the cheaper repair and it fixes one of the three — the plugin hook and the origin
claim are on the daemon and cannot be reached from a browser. It would also leave
the daemon's own log still saying four prompts and three ends, which is the thing
that was actually wrong.

**Not claimed: that every prompt now has exactly one end.** Four places in this
codebase say out loud that turns without one exist — an agent that died with its
turn, a daemon interrupted, a `/clear` that burns no turn number — and each builds
its own compensation. What closed is the one case where the daemon *watched* the
turn end and wrote nothing down.

**Measured.** `daemoncheck` drives a stub that answers `session/prompt` with
`-32603` carrying the upstream's own prose and **no** `errorKind` — the shape read
off the live log, and the reason `isAuthFailure` correctly ignores it and text
matching was never an option. It asserts the order (`error` then `turn_end`), the
reason, one end per prompt, and that no exit is recorded: a bad turn is not a dead
agent, and `onAgentUnusable` must not fire on one.

**Status.** Current

### Q2.220 — "It has no model called X. It is running X."

**Reported from the app, as a screenshot of one row.** A resumed opencode session
drew the error notice:

> opencode has no model called "opencode/hy3-free" — it offers
> openrouter/aion-labs/aion-2.0, … and 352 more. The conversation was resumed
> anyway, running opencode/hy3-free.

Both halves are true. The row is still wrong, and the way it is wrong is the
interesting part.

**`pinNativeModel` tests the wrong thing, and the two facts it conflates have
different answers.** It asks whether the model is in `option.choices` — what the
agent currently *offers* — and refuses when it is not. What the pin is *for* is
that the session runs the model. `option.value` is what it is running, and it can
sit outside `choices`: opencode resumed the conversation on the model it was
started with, while the list it publishes now reflects whichever provider keys the
machine holds today. So the session was on exactly what its preset named, and the
daemon announced a demotion that had not happened.

**This daemon already treats that state as normal at the other end**, which is what
makes the conflation a defect rather than a judgement call. Q2.219 narrows the
model menu to the session's own system and then says: *"The selected choice is
never removed, whatever namespace it is in"* — precisely so a session somebody had
switched by hand keeps a way back to itself. An agent that stopped listing the
model it is running is the same fact seen from the agent's side.

**Two consequences, and the second is the worse one.** `openResumed` drew a loud
`error` row — `agent-systems.md` calls it "the loud row on purpose" — about a
session that was fine, contradicting itself in one sentence. And `Session.start`
turns the same refusal into `SystemRoutingError`, so **a preset whose model the
agent is currently running answered a permanent `502`**. That is Q2.216's stranding
reached from the opposite side: that entry chose a demotion over a 502 that never
expires, and this produced the 502 anyway, for a pairing that works.

**Fixed by asking the right question first**: `option.value === wanted` returns
`null` before the list is read. Nothing to do, nothing to say — and one fewer
`session/set_config_option` round trip on every resume of a session already on its
model.

⚠ **The driver had a whole column for this and never drove the case.** The pinning
rig hardcoded `current: "sonnet"` while the pinned model was `"opus"`, so every
"the model is gone" cell was a genuine demotion — and the assertion *"the demotion
names both models"* is correct about the fixture and silent about the shape that
shipped. `current` is a parameter now and the four cells are pinned for
`current === wanted` too, including `start` answering `(started)` where it used to
answer `SystemRoutingError`.

**Status.** Fixed.

### Q2.221 — Is a refused `session/new` a fact about the credential?

**Reported from the app, as a screenshot of the New session sheet.** The strip
drew a tile reading `Gemini / from Bring yo…` — a harness the `byo` plugin adds —
and pressing Start answered:

> Gemini (gemini) rejected session/new: authentication required. Gemini refused
> this session. Run `gemini` once in a terminal on this machine to sign in with
> Google, or paste a GEMINI_API_KEY below.

The sentence is correct and the tile should not have been there. What made it
persistent is that nothing this daemon knows could have taken it away:
`readLoginState` answers `pasted ? true : null` for every harness with no status
command — which is opencode and every harness a plugin adds — so `loggedIn` was
`null`, `agentStance` answered `no_login`, and `offersTile` draws a tile for that.
Each press cost a worktree, a branch and a session row before the agent declined,
because the refusal happens *after* the spawn.

**Question.** The daemon now remembers the refusal. Does it belong on `loggedIn`?

**Decision. No, and the reason is not fastidiousness — it is that writing it there
closes the only door out.** `AgentAskRuns.admit` refuses on `loggedIn === false`,
and `admit` guards `claim`, which is what `GET /agents/capabilities` uses to start
a harness and read what it offers. That sweep is the **one** live re-measurement a
harness with no status probe ever gets: it performs a real `session/new` and caches
only successes. Route the refusal through `loggedIn` and the record blocks the
spawn that would have discovered the harness had been fixed — a lockout closing its
own last door, and one nothing on any screen could explain.

The narrower argument stands beside it. ACP's `auth_required` is answered by the
*adapter*, and Q7.65 is this repository's own counterexample: a pasted
`CODEX_API_KEY` that reached the model's API and was accepted, while `codex-acp`
went on refusing `session/new`. `loggedIn` answers "is this CLI signed in"; a
refusal answers "would this harness open a session, configured this way, a moment
ago". They are different questions and the second one is the one a tile is about.

So `AgentAvailability.lastStartRefusal` is its own field, carrying `at`, `routed`
and the message. `readLoginState` is untouched, and its own ⚠ now names where the
negative went — the docblocks at `runtime/types.ts`, `local.ts` and
`daemoncheck.ts:1525` all say a harness with no probe cannot report itself signed
out, and all three stay true.

**Two places write it and a third deliberately does not.** `Session.start` and
`Session.openResumed`, both on `isAuthRequired` — ACP's *typed* code rather than a
message match. Not the event pump's `errorKind: "authentication_failed"`: Q7.99
measured that against a session idle 5h36m whose token had 1.4 hours left, where a
fresh agent worked four minutes later. What is stale there is the process, and
`onAgentUnusable` carries a comment saying so at the one site that could have
written this.

**`routed` is what stops one refusal condemning a pairing it never tested.**
`applySystem` runs before `session/new` and returns whether it actually routed — a
native pairing configures nothing, because the agent already reaches its vendor on
its own credential. A refusal measured while routed has survived `providers/set`
and is evidence about every way of starting the harness. One measured bare is not:
that is the signed-out Claude Code on OpenRouter this repository documents as
working, and a fence reading a bare refusal as a fact about every start would have
deleted it. `registry.create` fences before `createWorkspace` — the same paragraph
the `available` check above it already carries, applied to the axis it did not
cover.

⚠ **And `customAgent == null` is not the whole test, which cost a draft.** A
**native** pairing carries a system and configures nothing: `applySystem` returns
at `spec.nativeHarness === options.agent`, before `providers/set` and before any
key is read, so the session runs on the harness's own credential exactly as a bare
start does — which makes a bare refusal precisely as dispositive. Written as two
disjuncts, the fence let through the one press that had just been refused, and
every repeat cost a worktree, a branch and a session row again. It resolves the
preset and asks the catalogue now. The case needs no plugin: `hostable` accepts
every native pairing, so a signed-out Claude Code with a native Anthropic preset
reproduces it.

⚠ **And the route that undoes it must answer the same row shape the listings do.**
`availability()` carries no `login` object — that is built in `loginSupportOf` and
spread onto `GET /agents` and `GET /agent-auth` by hand — so `POST
/agent-auth/:agent/recheck` returning its lookup verbatim dropped the one field
whose absence makes every reader fall to *cannot check*, which is the permanent
wrong badge `local.ts` answers `no_flow` to prevent. Measured: `pnpm client agents`
printed *no sign-in needed* and `pnpm client agents recheck` printed *cannot check*
for the same harness in the same state.

**Status.** Fixed.

### Q2.222 — A restart deleted five of the six conversations it was stopping

**Question.** What may the startup prune delete, and when may it delete anything
at all?

**Measured, 2026-09-04, host `cloud-09fce7b571`, read-only from the prod session.**
The daemon restarted at 14:46:18 UTC for the v0.6.0 deploy. The journal holds
`SIGTERM: stopping 6 session(s)` at 14:46:17 and `restored 1 session(s)` at
14:46:20, and nothing between them. The database now holds one row —
`s_bd274666`, opened 2026-08-31, last written 14:46:41 — and the file is
51,060,736 bytes on disk against `page_count × page_size` of 0.6 MB: the shape of
~50 MB of transcripts deleted in one operation and then vacuumed, which is
`reclaim()`'s trigger met in one boot. `reclaim()` runs only from `prune()`, after
its COMMIT, and `prune()` runs only from `openStores`. So the five were not lost on
the resume path. They were deleted by the store, in the three seconds between the
two journal lines, before `restore()` ever saw them.

**Root.** The age sweep read `SELECT id FROM sessions WHERE created_at < ? AND
pinned = 0` with `cutoff = now − 7d`. A conversation was condemned by the date it
was *opened*, however much it had been used since. Five of the six live sessions
had been opened before 2026-08-28 14:46; every one of them had been written to
seconds earlier by `doStop` under SIGTERM, carrying `daemon_shutdown` — the
daemon's own record that it meant to bring them back — and every one went with its
transcript. Nothing was logged: the ids `prune()` returns went up to `daemon.ts`
only to sweep upload directories, and the one `console.error` in the method fired
for the cap alone.

**Decision. Three rules, and a floor.** The owner's requirement, 2026-09-05: the
prune deletes *only inactive sessions*; a session the daemon itself stopped and
meant to restore is never deleted at any age; and nothing at all is deleted while
the table holds fewer than fifty. **And D27, the owner, 2026-09-05, after the
verification round**: the fix round's two calls stand — the floor is *kept*, a
prune never leaving fewer than `minSessions` rows ranked active first, then pins,
then most recently touched; and the cap bounds *inactive* rows only, so a live or
daemon-ended row is cut by neither sweep and the table may exceed the cap by its
active rows — and the hole those two left is closed: a row the daemon has
given up restoring on its own (`resume_gave_up` holding a value this build
honours) is not active, whatever its exit says — once it has one.

1. **Only an inactive session is ever deleted, by either rule.** A row is
*active* — and the prune never touches it, at any age, under any cap — when
it is live (no `exit_json`), when its exit `endedWithDaemon` (the daemon's own
promise to bring it back), or when its exit cannot be read: not JSON, not an
object, or a `reason` `isExitReason` cannot vouch for. `isExitReason` is new,
a `Record` so that a reason a newer build wrote is a value
this one may not act on — `compatibility.md`'s rule for which way an unknown
must fail, applied to a deletion. Unless the daemon has given it up: a row
whose `resume_gave_up` holds a value this build honours (`isPersistedGiveUp`,
beside `isExitReason` and for its reason — one it cannot name keeps the row)
is one the daemon will not put an agent back on by itself — the column is
written only when the agent says it no longer holds the conversation, the
one give-up `resumeGiveUpPersists` lets outlive a restart, and
`resumeSettled` keeps such a row out of the boot pass and the prompt route
alike; only a manual `POST /sessions/:id/resume` still can, and it clears
the column when it succeeds — so once it has an exit it is inactive whatever
that exit says, while a live row carrying the column is read as live first,
since the next boot comes back to it; the promise was the daemon's, and this
is the daemon recording that it cannot be kept on its own (D27).
`isActiveRow` is the one predicate, for both sweeps, reading both columns in
that order, and `DAEMON_EXIT_REASONS` has no copy in SQL. Every other reason
is inactive by decision rather than by remainder: `stopped` and
`agent_signed_out` were ended by a person (the sign-out has one writer,
`signOutSessions` under the logout route, so signing in again is that person
asking), `agent_exited` by the agent, `start_failed` and `start_timeout`
never had a conversation, and `agent_kill_failed` is a legacy value
`autoResumable` brings back on no trigger, so no promise is broken by taking
it. The age sweep takes an inactive, unpinned row whose `updated_at`, which
`put` stamps on every write that changes the row, is older than `retainMs`.
Activity, never creation.
2. **A prune leaves at least `DEFAULT_MIN_SESSIONS` rows.** Fifty. Rows are
ranked active first, then pins, then most recently touched first, and a row
within the floor is taken by neither sweep — so a table under fifty loses
nothing, and one over it keeps at least fifty: its active rows first, then
its pins, then the most recently touched of the rest, however stale.
The orphan sweeps still run, since they delete nothing anybody can see, and
`reclaim()` still runs, since its trigger — `freelist_count` against
`page_count` — counts pages freed by any delete since the last `VACUUM`, not
what the prune just took. `REEMOAT_MIN_SESSIONS` moves it, through
`positiveInt`, so `1` is the nearest thing to off and `0` reads as unset.
3. **The cap bounds the rows nobody is coming back to, and never the others.**
Among inactive rows, pins first, then most recently touched first, and the
rank past `maxSessions` goes: the least recently touched inactive row, a pin
only once every unpinned inactive row is gone, a live row or one the daemon
is still coming back to never. The table may exceed the cap by exactly its
active rows, since no cap could bound those without breaking rule 1. It used
to rank by `created_at`, so the newest-*opened* two hundred survived and a
conversation opened a month ago and used this morning was cut before an
empty one opened yesterday.

**And it says so.** One sentence through `onPruned` after the COMMIT — the count,
the split between idle and over-the-cap, every id, and that the transcripts went —
and nothing when nothing was removed. Its own callback rather than `onDegraded`,
because a prune is the store doing what it was configured to do: `daemon.ts`
prints one as `store degraded:` on stderr and this as `store:` on stdout with the
other facts about the boot, and the driver that collects degradations must not
find a routine deletion among them. Said outside the transaction's `try` and
guarded on its own, so a sink that throws cannot turn a committed deletion into
an empty list.

**Why fifty.** A quarter of `DEFAULT_MAX_SESSIONS`, and since the floor is kept
rather than gated the two bounds never meet whatever either is set to — a floor
above the cap leaves the cap nothing to cut. ~8 MB per session measured here, so
fifty is ~0.4 GB — what the floor lets sit on a disk, and nothing beside the
working trees those sessions were about. One person's dense week is 20–40
sessions, so a machine in ordinary use stays under it and the sweeps never run
across the list somebody is still scrolling. Below fifty a list *is* scrolled and
pruned by hand from the row's own menu; the sweeps are for the tail nobody will
scroll to.

**What still bounds the file.** The cap, on the rows nobody is coming back to:
two hundred, pins last, and it is still a deletion — the creation bound in
`registry.ts` is what keeps a loop from filling it. The rows the daemon is coming
back to sit outside every bound here, which is rule 1 and cannot be otherwise —
and the rows it has *given up* coming back to sit inside them, which is D27 and
closes the one class rule 1 had left unbounded. So the file holds at most the cap
in inactive rows plus the active ones, and those have bounds of their own: a live
row counts against `MAX_LIVE_SESSIONS`, and a daemon-ended row was a live one
under that ceiling, which the next boot restores or gives up.

⚠ **That last sentence stopped being true when parking landed, and this is the
correction rather than a second opinion.** A `parked` row is active —
`keepsItsConversation` is what `isActiveRow` reads — and it satisfies neither
bound the sentence names. It does not count against `MAX_LIVE_SESSIONS`, because
`liveSessionCount` counts `!terminal` and a parked session is terminal; and the
boot pass neither restores it nor gives up on it, because `autoResumable` answers
`parked` on a prompt alone. Nothing else moves it: `markInterrupted` returns early
on an existing exit record, `shutdown` iterates the live ones, and only a person
pressing Stop or a sign-out relabels it (`RELABELS_PARKED`). **So the active class
is unbounded again, by a different door than D27's.**

What made the old shape self-limiting was the thing parking removed on purpose: an
abandoned conversation used to hold ~400 MB and a slot, so a machine ran out of
ceiling long before it ran out of disk. A parked row costs neither, so nothing
pushes back. Measured on the development machine 2026-09-10, hours after the
feature landed: 5 parked rows of 12. Second-order, and the sharper half — `active`
counts parked rows into the floor (`if (active + rank <= options.minSessions)`),
so a machine holding fifty parked conversations has spent the whole 50-row floor
on rows that were never at risk, and it stops protecting the inactive ones it was
written for.

**Deliberately not bounded yet, and that is the decision rather than an
oversight.** A parked conversation is one somebody is *expected* to return to,
which makes it the last row a prune should take — an age bound here is Q2.222
pointed at the quietest sessions instead of the busiest, and there is no
measurement behind whatever number it would pick. At ~8 MB a session the runway is
years. What is owed is this paragraph, so the next person to read "the file holds
at most the cap" does not believe it, and a look at real numbers before a bound is
chosen. If one is wanted, the shape to weigh first is excluding parked rows from
the floor's arithmetic — it loses nothing recent and restores what `minSessions`
was for. At ~8 MB a session
the cap is ~1.6 GB of transcripts nobody is coming back to, and the floor's
~0.4 GB is the part of that which may sit there however stale. And `reclaim()`,
on bytes, whose condition is independent of what the prune removed and says so in
its docblock.

**Read back, 2026-09-05, the verification round.** Three verifiers drove the first
cut of these rules against stores of their own and found the code short of the
sentences in four places, each of which is a pin now — and the owner's read of
the fix round found a fifth, and the follow-up's own verifiers a sixth:

- *The cap cut what rule 1 kept.* It ranked `pinned DESC, active DESC` across the
whole table and cut past two hundred regardless, so "cut last" was "cut": two
hundred pins put every live row and every row the daemon had just stopped over
the cap at the next boot, and a hundred and fifty interrupted rows beside
fifty-one live ones cut the least recently touched interrupted row. And its
`active` was a SQL `CASE` — `json_valid`, then a reason list — so a reason this
build cannot name, `null`, a bare string, `{}` and `{"reason":null}` all ranked
inactive and were cut while the sweep kept them. The cap ranks inactive rows
only now, through the sweep's own predicate, and nothing reads the JSON in SQL.
- *The floor was a gate.* `count >= minSessions` before any delete: a table of
exactly fifty lost forty-nine in one boot, and a cap set under the floor cut
under it, while the rule file said "never under 50 rows" and the constant's
docblock said the two bounds "never meet". A floor that is *kept* implies the
gate and not the other way round, so it is the floor.
- *`onPruned` was called inside the transaction's `try`.* A sink that threw ran
ROLLBACK against a committed transaction, skipped `reclaim()` and returned
`[]` over rows that were gone — the list `daemon.ts` sweeps upload directories
from. Latent, since `console.log` does not throw.
- *Four of the nine reasons were swept with nothing saying so*, and the replay
was not row for row: its sixth row was live and eight days idle where the
incident's was a `daemon_shutdown` opened four days before. Both read as
stated above now.
- *A row the daemon had given up on was active for ever.* Found after the fix
round, and closed by the owner's decision D27 (2026-09-05) that kept that
round's two calls — the floor kept rather than gated, the cap on inactive
rows only — and named the hole they left. `isActiveRow` read `exit_json`
alone, so a `daemon_shutdown` row whose next boot wrote `resume_gave_up` (the
agent said it no longer held the conversation, the one give-up
`resumeGiveUpPersists` keeps across a restart, after which `resumeSettled`
takes the row out of both automatic paths) still read as the daemon's promise
to come back: swept by no age, counted under no cap, a class nothing bounded
and one that grew by a row for every conversation an agent forgot.
`isActiveRow` reads both columns now — `resume_gave_up` non-NULL is inactive
whatever the exit says — and is driven under both sweeps beside a twin with
the column NULL. The one such row the boot pass does still touch is a
conversation `conversationKnownEmpty`, which it recreates rather than
restores, since the conversation the agent is asked for is empty by
construction; what a deletion loses there is the empty conversation the pass
would have reopened under the same title and worktree and, for the cleared
arm, the events before the marker, which `/clear` truncates nothing of —
they go with the row as every inactive row's log does.
- *Two rows the column alone misread, and a sentence half pinned on nothing.*
Found by the follow-up's verifiers, the same day. A live row carrying the
column — the shape `doResume` leaves on disk for the length of every
recreate, exit cleared and column not yet — was inactive, so a crash inside
that window left a row the next boot's prune deleted under the sentence
saying a live session never is; `isActiveRow` reads live first now. And any
non-NULL value was inactive, on the argument that the store may not read the
registry's vocabulary, while the registry reads a value it cannot name as
"not given up" and restores the row at boot — so a downgrade from a build
persisting a second value would have deleted exactly what the boot pass was
coming back to, the rollback case `isExitReason` exists for on the other
column. `isPersistedGiveUp` sits in `events.ts` beside it now, and both
readers go through it. And the floor half of the one sentence the journal
carries was pinned on nothing, so the wording it replaced came back green
under a mutation; it is pinned. Both rows are driven under both sweeps.

**Alternatives taken out.**

- *Keying the age sweep on `last_event_at`.* It is NULL for a session that never
produced an event and does not move on a rename, a pin or a stop, all of which
are somebody touching the conversation. `updated_at` moves on every `put` that
changes the row.
- *Filtering the daemon exits in SQL with `json_extract` in the `WHERE`.* A second
copy of `DAEMON_EXIT_REASONS`, and one malformed `exit_json` would have thrown
the whole prune into `ROLLBACK`, orphan sweeps included. The cap's ranking read
the JSON that way for one commit, guarded by `json_valid` and parameterised from
the constant, and that guarded copy is the one that disagreed (above).
- *Ranking active rows first under the cap and cutting past two hundred
regardless.* Bounds the table to exactly two hundred, and makes whether a pin
survives depend on how many sessions were live at the last restart — and it is
a cap that deletes what rule 1 says is never deleted.
- *Clamping `REEMOAT_MAX_SESSIONS` up to `REEMOAT_MIN_SESSIONS`.* Unneeded once
the floor is kept: a row within it is taken by neither rule, whatever the cap
says.
- *Reporting through `onDegraded`.* The prefix would have read `store degraded:
pruned 5 session(s)` over the store doing exactly what it was told, and the
`degraded` array `daemoncheck` asserts on would have carried a routine line.
- *Skipping `reclaim()` under the floor.* Its trigger is about the file, not the
transaction; a quarter of the file can be free from `DELETE /sessions/:id` on
any day since the last `VACUUM`.

**Driven.** `daemoncheck`, in `daemoncheck.store-and-worktrees.ts`, against a
store of its own: the incident replayed row for row (five opened eight days ago
and one four days ago, all six written a minute ago with `daemon_shutdown` — none
pruned, with and without the floor); every `ExitReason` under a floor of zero, off
a `Record` so a tenth reason is a compile error until
it is placed; forty-nine stale rows under a floor of fifty, then the fiftieth, then
sixty; a cap under the floor and a floor above the cap; two hundred and eight rows
whose `updated_at` and `created_at` run in opposite directions, beside eight the
cap may not touch and each touched less recently than any of them; more active
rows than the cap, and more pins than the cap; a `daemon_shutdown` row the daemon
has given up on, under the age sweep and under the cap, each time beside its twin
with `resume_gave_up` NULL, a live row carrying the column, and a
`daemon_shutdown` row carrying a value this build cannot name; the one sentence,
its split and its floor half; a
sink that throws; the floor and the window through `openStores` with neither
option given; and the daemon's wiring off the entry script's text. Every pin was
proven red against the old statement, against the first cut's store, or under a
one-line mutation.

**Status.** Fixed, 2026-09-05.

### Q2.223 — "this machine already has 6 live sessions", on a daemon that may well have had eight

**Question.** The owner hit the live-session cap on a provisioned cloud box and
asked the fair question: *"почему у нас существует какой то лимит сессий? его не
должно быть, либо обоснуй понятным языком, зачем он нужен"*. Two things had to be
answered — where the 6 came from, and whether the bound should exist at all.

**Where 6 came from.** Not from this repository. `MAX_LIVE_SESSIONS` is 64;
`services/premium/cloud-init/provision.sh` writes `REEMOAT_MAX_LIVE_SESSIONS='6'`
into `~/.reemoat/daemon.env` once, at provision, with its own arithmetic above it:
*"The default is 64 and this machine has 8 GiB, so 64 is not a bound — it is a
promise of an out-of-memory kill. Six is arithmetic… Revise it against a real
box."* Nothing in `deploy/` ever rewrites that file, so an update never touches it,
and `maxLiveSessions` is on no route and in no snapshot — **the refusal string is
the only place in the product this number is visible.** Which is why the number
could not be found from the phone that hit it.

**Decision on the bound.** It stays, and it is not one bound but two — Q2.100's
pair. Of the four reasons behind it, exactly one still applies to a single-owner
machine, and it is the decisive one: **memory**. Agents are spawned `detached`, a
new process *group* and not a new cgroup, so they live in the daemon's own cgroup
and no cgroup arrangement protects the daemon from them; the premium box runs
`earlyoom` with `node` among its preferred victims and the daemon is itself a
`node` process. Removing the ceiling trades a refusal that names its remedy for an
OOM kill of an agent mid-turn, on a phone, with nothing on screen explaining why.
The honest fix is a bigger box or `SessionRuntime`, both of which are somewhere
else.

The other three are weaker than the docblock reads, and saying so is the point of
this entry. The prune taking somebody's transcripts is largely defused by Q2.222's
floor and rules, and was never the live cap's job anyway — the *burst* is that
half, and it survives independently. The shared-machine case needs a grantee. And
the multi-tenant container case does not exist in this product any more.

**What changed instead.** The sentence. It interpolated `maxLiveSessions` — the
*limit* — inside a clause claiming a *count*, and the two coincide only at the
boundary: **resume is deliberately outside the bound**, so a restart that brings
eight conversations back leaves a daemon truthfully holding eight while the
refusal insists on six. It now states the limit as a limit and names
`REEMOAT_MAX_LIVE_SESSIONS`, because a number visible in exactly one string should
say what to search for.

**Not done, and each for a reason.** Removing the live cap: it is the last named
bound on a plugin whose `session.created` handler calls `ctx.sessions.create`, and
three separate docblocks quote it as the worst case they escaped. Raising the
default from 64: a no-op for the machine that reported this, which reads the env
var. Making it settable from the UI: *the daemon's config is env only*, and there
is no per-machine settings table or route to put it in.

**Status.** Active

### Q2.224 — A session nobody had touched in two days was still holding 476 MB

**Question.** What bounds the memory a machine spends on agents, and how long may
a conversation nobody is using keep one?

**Measured, 2026-09-09, the development machine (darwin 24.6.0, Apple silicon),
against the live daemon `i_b71a1ed2` and its own event log.** Nothing here had ever
been measured; there is no memory harness in this repository and never has been.

macOS `phys_footprint` — the honest figure, excluding shared framework pages and
including compressed memory. Five live sessions:

| Session | Idle for | Processes | footprint | peak |
|---|---:|---|---:|---:|
| `s_e3cc64` claude | 1.5 h | acp bridge 80 MB + `claude` 261 MB | 341 MB | 396 MB |
| `s_5d26f9` claude | 6.4 h | acp bridge 82 MB + `claude` 177 MB | 259 MB | 403 MB |
| `s_a55fb1` opencode | 48.7 h | one process | 476 MB | 760 MB |
| `s_1bf6a1` opencode | 48.7 h | one process | 447 MB | 674 MB |
| `s_1fa7f6` opencode | 48.7 h | one process | 461 MB | 736 MB |

**1 984 MB for five conversations, of which 1 384 MB — 70% — belonged to three
nobody had touched in 48.7 hours.** All three were `idle`: no turn, no unanswered
permission, no question. Sampled again twelve minutes later they had moved by under
2%, so an idle agent does not give the memory back on its own. The daemon itself was
105 MB and its plugin child 31 MB.

The other half, from the same log: `status:interrupted` → the next `agent_config` on
that session is exactly a spawn, an ACP `initialize`, a `session/resume` and the
config arriving. 120 real reattaches:

| Agent | n | p50 | p90 | min | max |
|---|---:|---:|---:|---:|---:|
| claude, resuming alone | 28 | **1 292 ms** | 2 376 ms | 487 ms | 5 619 ms |
| kimi, resuming alone | 21 | 2 806 ms | 2 861 ms | 713 ms | 12 945 ms |
| opencode (only ever in 3-way boot storms) | 44 | 3 298 ms | 26 929 ms | 1 442 ms | 52 843 ms |
| claude, in a 3-way boot storm | 27 | — | — | 541 ms | 90 182 ms |

A cold `session/new` is 695 ms mean for claude and 1 065 ms for opencode, so a
resume is about twice a fresh start and most of both is process startup. **The trade
is therefore ~397 MB against ~1.3 s.** The boot-storm rows are the second finding:
resumes contend badly, and three at once turned a 1.3 s reattach into 90 s.

**Root.** `MAX_LIVE_SESSIONS` was checked in exactly one place, `create()`. Nothing
ever released an agent, so the ceiling bounded how many conversations somebody could
*open* and never how many agents a machine ends up holding. Its own docblock had
conceded the point for a year — *"a machine running 64 agents at once has run out of
memory long before it runs out of slots"* — and then done nothing about it.

**Decision. Release the agent, keep the conversation.** A session idle for
`REEMOAT_IDLE_PARK_MINUTES` (30, `0` off, **on by default**) is stopped with a new
`ExitReason`, `parked`. The process goes; the transcript, the `agent_session_id`,
the worktree, the branch and the title do not. The next message starts an agent and
carries on over the same `session/resume` the daemon already performs after each of
its own restarts.

⚠ **That sentence was one case too wide, and the case is now guarded.** Work the
agent left running in the background dies with the process — the CLI kills what it
backgrounded when it is shut down, and a resumed agent is told nothing about it —
and `parkable` could not see it, because a session whose turn has ended reports
`idle` honestly. Measured on this machine: `s_5d26f98e` released 60m14s after its
last event with nothing moving the clock in between. A clause refuses over work
claude *reports*, and the rest of the fleet is still covered only by the margins.
Q2.228.

Almost none of this is new machinery, which is the argument for doing it this way.
`terminal` is `exitRecord !== null`, so a stopped session already holds no process,
is already skipped by `liveSessionCount`, already keeps its conversation and already
comes back through `resume()`. Parking is `stop("parked")` plus a rule about when it
returns.

1. **The preconditions are one comparison: `status === "idle"`.** (Three clauses
have been added beside it since — a `/clear`, a queued message, and live
background work, each a state `status` reports as an honest `idle`.) The three states
parking must never interrupt — a turn in flight, an unanswered permission, an
unanswered question — are exactly the ones the derivation reports as something
else, along with the two where there is nothing to release yet or already. A
hand-written list would fall out of step with `status` the day a fourth waiting
state is added; this cannot. Plus `agentSessionId !== null`, or parking is a
one-way door.
2. **`parked` is deliberately not in `DAEMON_EXIT_REASONS`.** That list means "the
daemon owes this back **by itself**", and it drives the boot pass. Un-parking
everything at the next restart would hand back all the memory at once, in the
contention the measurement above found. So `autoResumable` answers `true` on a
prompt and `false` at boot, and `markInterrupted`'s existing `if (this.exitRecord)
return;` leaves a parked row parked across a restart with no new code.
3. **It derives its own `SessionStatus`, and the reason is a defect avoided rather
than a preference.** `ManagedSession.status` reads `endedWithDaemon` and then
falls through a `switch` whose `default:` answers `exited` — the word for a
conversation somebody ended. A reason outside that list lands there silently and
compiles clean, because unlike `autoResumable` this switch has a default. The
client had the identical hazard one layer up: `statusTone`'s own `default:`
answers `idle`, which would have drawn a live dot over a machine running nothing.
4. **The ceiling releases a slot rather than refusing**, which is what turns it
into a memory budget — see Q2.100. Least recently active first, one slot, on
**both** ends: a wake that would cross it, and a `create`. They differ only in
the last resort: a wake goes one over on purpose, because somebody typing into a
conversation they already have must never be told it is unavailable; a `create`
refuses, because new load is exactly what a ceiling has to be able to say no to.

⚠ **The threshold does not apply at the ceiling, and that is a correction.**
Both paths first measured candidates against the full 30 minutes, so six
sessions that had finished five minutes ago blocked a seventh for the rest of
the half-hour — and the refusal told the person to *stop* one, which ends the
conversation and files it under Ended. The daemon was asking somebody to do
destructively, by hand, what it could do losslessly one line earlier. **The
sweep releases by age, because nobody asked; a ceiling releases by need, because
somebody is asking for capacity now.** What stays untouchable is what must be —
`parkCandidates` takes only sessions whose derived status is exactly `idle`, so
a turn, an unanswered permission and an unanswered question are safe at any
ceiling — and a machine whose owner set `REEMOAT_IDLE_PARK_MINUTES=0` is refused
rather than having an agent taken anyway.
5. **A message is the only way back, and nothing on screen says so.** No Resume
control is drawn — an active exclusion, since `canResume` is `isTerminal &&
isResumable` and a parked session satisfies both. The composer is unconditional
(Q7.103), so the affordance already exists; a button offering to undo
housekeeping invites somebody to sit on a session list waking agents one at a
time.
6. **It is drawn as an ordinary quiet session — same dot, no notice.** `statusTone`
answers `idle` for it, explicitly rather than by fallthrough (the fallthrough
answers `ended`), and `sessionNotice` returns `null` before the catch-all that
would otherwise draw `exitText` in the shape of a conversation that ended.
Whether a process is resident is not a fact about the conversation, and not
something a reader can act on. What it is *not* drawn as is equally deliberate:
not `ended`, because nobody ended it, and not counted in the machine's live
count, because nothing is running. The dot answers what the *conversation* is
doing; the count answers what the *machine* is doing, and parking is the case
that separates them.

7. **Its controls stay live, and a tap is a choice rather than a wake.** (⚠ And
its **command list** stays too, which this point missed and Q2.228 repaired: the
same argument applies word for word, and withdrawing it left a parked session
with a working model picker and an empty `/` menu under a composer reading *Type
/ for commands* — 111 commands live, 0 parked, measured.) Every
other stop clears `agentConfigState`, which is right — the options describe a
process that is gone. Parking keeps them, because the process is coming back to
the same conversation, and clearing them made the strip fall to the client's own
memory, where it is drawn faint and refuses a tap: a session you could re-model
at 29 minutes and not at 31, with nothing on screen saying why, since parking
deliberately shows nothing. So the options stay, `setConfigOption` and `setMode`
**record** against them instead of sending, and `doResume` puts the choice to
the fresh agent through `restoreConfig` — which sends only what differs and only
what the returning agent still offers. The owner's rule, and both halves are
load-bearing: recording without applying is a control that lies, and applying by
waking would spend ~400 MB on a glance at a settings row and give the feature a
second way back when its whole answer is *send a message*. In memory, so a
daemon restart drops a pending choice and the strip reads faint again — the
honest state for a daemon that no longer knows what that agent offered.
Validation is the live path's, run against the remembered options, so a value no
agent offers is refused without one rather than recorded and silently dropped at
the wake.

**The trap, and it is the one worth remembering.** `isActiveRow` — the prune's
predicate — ended `reason === null || endedWithDaemon({ reason })`. Since `parked` is
deliberately outside that list, adding the reason made **every parked session
inactive**: swept by age, ranked under the cap. That is Q2.222's incident exactly,
re-aimed at the quietest and most-likely-to-be-returned-to conversations on the
machine. `events.ts` now exports `keepsItsConversation`, one member wider, and the
store reads that; `endedWithDaemon` is untouched, because the boot pass and the
client's warn tone still want the narrow question. Nothing in the type system would
have caught this — the function has no `switch` — and what did catch it is the
`Record` Q2.222 left behind in `daemoncheck`, which
refused to compile until the new reason was placed.

**What the wake actually costs, measured 2026-09-09, and why none of it is
recoverable.** Spawning the ACP bridge and completing `initialize` is **197 ms**,
timed directly against `claude-agent-acp` with no session opened. `session/new` on
top of that is ~500 ms — the `claude` CLI's own start — and `session/resume` ~1 100
ms, so re-reading the conversation is the remaining ~600 ms. Two thirds of the wake
is inside the agent's own binary.

⚠ **The transcript this daemon holds cannot shorten any of it, and the protocol is
where that is settled rather than the implementation.** `ResumeSessionRequest` is
`{sessionId, cwd, …}` and `LoadSessionRequest` is `{mcpServers, cwd, …}` — neither
carries history, so there is no verb for handing an agent a conversation. What
`sessions.events` holds is what the *browser* draws; the agent's context has to come
from the agent's own file, which for claude is `~/.claude/projects//.jsonl`
(Q2.1). The daemon's resume *is* the CLI's own: the live fleet shows
`claude … --resume=` on the command line.

**And that is also the answer to "what do claude and codex do about this".** They
have no resident process at all — a CLI session lives exactly as long as its
terminal, and coming back is `--resume=` re-reading the transcript, at the
same ~1.3 s. **The daemon was the deviation**, holding processes indefinitely
because it had no notion of the person having closed the terminal. Parking is what
makes it behave like the tools it wraps.

**Alternatives taken out.**

- *A warm spare process.* It cannot help with the expensive part: the CLI is bound
to a conversation at spawn (`--resume=` is a launch argument), so a spare
cannot be pre-pointed at one. Only the *bridge* could be kept warm, saving the
197 ms — about 15% of the wake — for a resident process per spare. Paying memory
to buy back latency is the trade this whole entry exists to make in the other
direction.
- *A mark and a sentence of its own.* Built first: a dashed dot, a screen-reader
label, and a quiet notice saying the agent had been released and a message would
bring it back. All of it removed. The person cannot act on any of it, the wait it
would have explained is already covered by the composer's spinner, and a state
with a name is a state somebody has to interpret. See point 6.
- *Adding `parked` to `DAEMON_EXIT_REASONS`.* It fixes the prune in one word, and
then the boot pass un-parks everything and clients draw the warn tone
`interrupted` carries. Two wrong answers to buy one right one.
- *Refusing a wake at the ceiling, the way `create` used to.* It is the same 429
and a completely different sentence: one says "you have too many sessions open",
the other says "the conversation you are typing into is unavailable". Releasing a
slot is refusing something nobody is watching instead.
- *Keeping the full idle threshold at the ceiling.* Argued for a round, on the
ground that a machine with nothing idle for half an hour is genuinely that busy.
It was wrong about who is asking: at a ceiling somebody is asking for capacity
now, and what would be taken is an agent doing nothing. Q2.223's complaint
survived the whole of Q2.224 because of it.
- *Waking on opening a session.* Asked for, and declined by the owner: it hides the
1.3 s behind reading the transcript, and it means tapping through five rows spawns
five agents. Typing is the signal that somebody actually wants the agent.
- *Scaling the sweep interval to the threshold.* Somebody who sets five minutes
would silently get a coarser sweep than somebody who sets an hour. A minute of
slack on any threshold is noise; the interval is a constant.
- *A `resume_gave_up` precondition as a live gate.* It is written, and it cannot
fire: `onResumed` clears the verdict on the resume that succeeded, so a session
live enough to be idle has just proved it can be brought back. Established by a
driver fixture built to exercise it, which parked anyway. Kept as a statement of
intent, with the reason recorded at the site and both halves pinned.

**Driven.** `daemoncheck.restart-and-resume.ts`: the `autoResumable` row on both
triggers; `statusOf("parked")` against `"parked"` *and* against `"exited"`, since
the failure is two states collapsing into one; a real open turn the sweep must not
take, against a rig that never answers the prompt; the four facts "released" means;
a restart that finds it still parked and a boot pass that leaves it alone; a wake
through the real HTTP route, on the same `agentSessionId`; eviction at the ceiling,
least-recently-used first, from both ends: a wake taking a slot and proceeding
anyway when there is none, and a `create` taking one — losslessly, the session
ending up `parked` rather than ended — and still refusing before it touches the
filesystem when every live session is mid-turn; and the schedule itself through an
injected clock, including that it re-arms.
`daemoncheck.store-and-worktrees.ts`: `parked` placed as `"kept"`, driven under both
sweeps. And the deferred controls, against a rig that publishes an option and
accepts `session/set_config_option`: that a released session still offers it, that
choosing is accepted, that the choice is on the session at once and **no process
was started for it**, that a value the agent does not offer is still refused, that
the wake sends exactly what was chosen — and the negative that keeps the arm
narrow, a session somebody *stopped* keeping no controls and answering `terminal`.
⚠ The rig was written in this daemon's own `kind`/`value`/`choices` shape rather
than ACP's `type`/`currentValue`/`options`, so `toConfigOptions` produced an option
with no kind and no choices, both validation guards were skipped, and a model no
agent offers was accepted and then sent. The driver caught it; nothing else would
have. `webcheck`: the three-way exit-reason partition with `parked` its own part;
that `endedWithDaemon` is *not* exact about it and `isParked` is what runs first;
the four-way presentation partition over the whole matrix; its own tone, asserted as
distinct from `ended`, `idle` and `waiting`; its dot read off disk and asserted
different from the ended one, because a `Record` cannot catch a copied string; that
it lands in Active and not in the machine's live count; and the absence of the
Resume control. Every one was proven red under a one-line mutation.

**Status.** Fixed, 2026-09-09.

### Q2.225 — The first daemon setting with a control on a screen

**Question.** How long a conversation keeps its agent (Q2.224) is one person's
trade between memory on their own machine and a ~1.3 s wait. It shipped as
`REEMOAT_IDLE_PARK_MINUTES` — an env var, edited over SSH. Should it be on the
settings screen, and if so what happens to *"the daemon's config is env only"*?

**Decision.** It gets a control, and the rule does not move. `REEMOAT_*` is still
read only in `scripts/daemon.ts`, nothing in `src/` touches `process.env`, and an
operator provisioning a fleet still writes an env file. What is new is a **narrower
class** with a different owner: settings whose subject is the person *using* the
machine rather than the one who deployed it. `agent_strip` — which agents the New
session row offers, and in what order — has been in that class since it was built
and only escaped the question because one preference needed no general home.

- **`machine_settings`, a key/value table**, and a new *table* so `SCHEMA_VERSION`
stays 6 for the reason `uploads` and `plugins` already give. Keys are enumerated
in `MACHINE_SETTING_KEYS`, a `Record<…, true>` exhaustive in both directions, so
a row this build cannot name is left alone rather than half-understood — the
stance `isExitReason` takes on a different column. A column per setting would
have made that a migration.
- **`GET /settings` and `PATCH /settings`.** `PATCH` and not `PUT`, which is the
opposite call from `/agent-strip` one route above: that body is a whole list and
replacing it wholesale is the only coherent write, while this is a table of
independent settings where a client sending the keys it happens to know would
silently reset the ones it does not. An older client must be able to write this.
- **A stored value overrides the env var**, which is therefore the default for a
machine nobody has set rather than a policy anything has to explain itself
against. `0` is a stored answer of "never".
- **Applied to the running daemon before the route answers**, not at the next
restart, so the value a caller reads back is one already in force.
- **A store-less daemon still answers `GET` and refuses `PATCH`.** The number is a
fact about the machine either way; what a person cannot do is change it, and a
`503` says so where an empty form would say nothing.

⚠ **The provenance line was built, shipped into review and cut, and the reasoning
that put it there is worth keeping because it looked correct.** The screen first
drew a line under the field saying whether the number was set here or came from
this machine's configuration, with a link back to the latter — on this
repository's own rule that a control must not show a value a configuration has
silently answered, which is why the agent settings screen reads
`~/.claude/settings.json` and says so. The owner cut it on sight, and the rule was
being misapplied: it is about an operator and a user disagreeing, and here there is
no operator. This is one person's machine and one person's preference, so the line
was a sentence about env files on a screen that mentions none. What went with it is
the whole apparatus it justified — `source` on the wire, `null` on the route,
`clear` on the store — because the only thing any of them could express was "go back
to the configuration", and with no line there was no reader. An unread field is the
state this repository deletes rather than keeps. The way back to the default is
typing the number.

**The copy, and it is a decision rather than a detail.** One sentence — *"A
conversation left untouched this long has its agent shut down to free memory, and
your next message starts it again exactly where you left off"* — and the word
**park** appears nowhere a reader can see it. That is the owner's call and it is
right: the daemon calls this state `parked`, every docblock does, and that is
exactly how the word leaks onto a screen — it is the name everybody working on it
uses. On a settings row it would name a mechanism the reader cannot see and cannot
act on, turning housekeeping into a term to learn. `webcheck` asserts the
prohibition over the whole comment-stripped screen rather than over the sentence,
because read off the sentence it passes vacuously the moment somebody rewords it —
which is precisely when they are most likely to reach for the word. The other half
is asserted too: the sentence must still say that the agent is shut down and that
nothing is lost, or "no jargon" is satisfied by saying nothing.

**Alternatives taken out.**

- *Leaving it env-only, per Q2.223.* That entry refused a UI for
`REEMOAT_MAX_LIVE_SESSIONS` on this exact rule, and the refusal stands **for that
setting**: a ceiling on concurrent agents is a machine's operator's business.
This one is not — it is a latency preference, and the person meeting the latency
is the person holding the phone.
- *A column on the singleton `daemon` table.* That table is the running instance —
`instance_id`, `pid`, `started_at` — and is rewritten at every boot. A persisted
preference in it would be a preference that looks like state.
- *A general settings framework.* One key today, and the table is the general part;
what is deliberately absent is a schema, a types-per-key registry and a
migration story for a surface with one member.

**Driven.** `daemoncheck.restart-and-resume.ts`: the configuration in force with
nothing stored; a save that answers with what is now in force **and is already
being used by the running daemon**, which is the half a caller cannot check for
itself; a session released on the saved five minutes that the configured
forty-five would have kept; `0` surviving the round trip as a choice rather than
being read as unset, and `null` no longer being a way to ask for the configuration
back; an unknown key, a negative, a fraction and a value past the ceiling all
refused without changing what is stored;
and a store-less daemon answering `GET` and refusing `PATCH`. `webcheck`: the
sentence, the prohibition over the whole screen, and that no heading on it names
the mechanism either.

**Status.** Current, amended by Q3.686: the sentence is the idle row's subline, "Shut
down, then resumed where you left off.", and the setting is a pick of nine presets
rather than a typed number.

### Q2.226 — Can somebody correct the agent without stopping it?

**Question.** Until now, no. `ManagedSession.prompt` answered `busy` while
`this.turn !== null`, the route turned that into `409 turn_in_flight`, and the
composer refused Send — so the only way to change course mid-run was to press
Stop, which ends the turn and throws away whatever it had half-done. The ask was
the behaviour Claude Code has: type the correction, and it is taken.

**Rule.** A message sent while a turn is running is **accepted**, and how it
reaches the agent is the agent's own answer:

- Where the agent advertises `_meta.steering.supported` on `initialize`, the
daemon sends the ACP extension `_session/steering` and the message goes **into
the turn already running**. claude and codex both do.
- Where it does not, `ManagedSession` **holds** the message and delivers it the
instant the turn ends. kimi does not, and opencode is unmeasured.

Both answer `202` carrying the same `seq`, distinguished by `steered` / `queued`
so a client knows what to say and never whether the send worked.

**Why not a second `session/prompt`.** Because it means two different things on
two agents and one of them is destructive. Measured 2026-09-11 by reading the
pinned adapters: claude-agent-acp 0.73.0 queues a second prompt FIFO
(`turnQueue`, and it advertises `agentCapabilities._meta.claudeCode.promptQueueing`),
while codex-acp 1.8.0 keeps **one** `activePrompt` per session and every
continuation of the first checks `this.activePrompts.get(sessionId) !== activePrompt`
and bails — a supersede that silently abandons a live turn. `Session.turnActive`
and `ManagedSession.turn` both assume one turn either way.

**Why the queue is the daemon's.** `attach.ts` had already named the two failure
modes against building one — *"a session that ends, a tab that closes"* — and both
are failure modes of a **client-side** hold, which is what had been built and
withdrawn twice before (most recently the plan card's, Q3.454). Neither exists
here: a closed tab is not holding anything, and a session that ends drops the
queue and writes an `error` event saying so.

**Where it is delivered, and why that is the last statement in the block.**
`deliverQueued` runs at the very end of `pump`'s `finally`. `sweepPending` in that
same block is **not** fenced on turn identity, so a turn started any earlier would
have its own freshly-raised permissions cancelled by the previous turn's sweep.
`whenRestarted` and `clearContext` call it too, because a restart and a clear are
two of the three states it declines in and something has to pick the queue back up
on the way out.

**One rule for the log.** A `prompt` event is appended when the daemon **accepts**
a message — which is what that event's own definition has always said — in all
three landings, and never a second time on delivery. That is what gives the client
a `seq` to settle its echo against, puts the bubble where the message was written,
and makes the queue a fact about *delivery* rather than about the conversation.
Whether a taken message is still waiting rides the **snapshot**
(`queuedPrompts`), which is `cancelRequestedAt`'s arrangement from Q2.42 and is
here for the identical reason.

**In memory, and the cost is written down rather than hidden.** A daemon restart
drops the queue — the same standing the interrupted turn itself has (Q2.12) — and
what survives is the transcript showing the message with no answer under it. A
**stop** is the case that can be reported, and is: `doStop` writes one `error`
event counting what never arrived, because each queued message is already a
`prompt` with nothing after it, which is precisely the shape Q2.218 named as a
message that reached no model.

**Two guards that are not obvious.** `parkable` answers `false` with a non-empty
queue: `status` reads an honest `idle` between the turn ending and the queue
draining, and `releaseOneSlot` asks with an `idleMs` of `0`, so the ceiling could
otherwise take the agent away from a message the daemon had already accepted,
recorded and spent the uploads for — the eighth caller of the "one process
boundary at a time" rule the `clearing` marker states. And the queue bound
(`MAX_QUEUED_PROMPTS`, 8) is checked **before** anything is appended, because on
the steer path the queue is only reached once the steer has failed.

**Rejected.** Cancel-then-prompt for the agents that cannot be steered — what
Q3.454's plan card does. It gives an immediate pickup on all four, and it throws
away the in-flight turn, which is the one thing this feature exists not to do.

**A cancel delivers what is waiting**, and that is decided rather than incidental:
it makes *type the correction, press Stop* one gesture that steers a queueing
agent — the same act Q3.454 performs from the other direction. There is
deliberately no way to take a queued message back (no ✕, matching Claude Code), so
Stop cannot also mean "and forget what I said": dropping it there would lose typed
text in silence, which is the failure this codebase does not ship.

⚠ **Three defects found in review, all of them about *when* a guard was taken, and
recorded because each was invisible to the drivers that existed:**

- **An agent restart is not a stop.** `restartAgent` reaches its boundary through
`stop("config_changed")`, so `doStop`'s drop threw the message away and wrote
*"the session stopped"* into a session that had not stopped — reached from
`onAgentUnusable`, i.e. an agent dying mid-turn, which is the likeliest turn to
hold a correction. The queue survives the three reasons `autoResumable` calls
the daemon's own doing.
- **A stop landing inside the steer walked past every guard**, because all of them
are taken before `sendMidTurn`'s two awaits. It answered `202 {queued: true}`
for a terminal session, said nothing (the drop had run while the queue was still
empty), and left an entry on every snapshot of a dead session for ever.
- **`steered` could answer `turn: null` against a declared `number`** — TypeScript
keeps a property narrowing across an `await`, so `this.turn` read as `number`
while `pump`'s `finally` had cleared it. The turn is captured before the awaits
now, which is also the honest value: it names the turn the agent injected into.

**And two assertions that were green over nothing**, found by mutation: the
`parkable` queue clause is refused at `status !== "idle"` long before it is
reached — it is unreachable as the code stands and kept as a refusal, beside
`resumeGivenUp`, which is in the same position — and `idleBehavior:
"promptRequired"` was asserted nowhere at all, so deleting the whole opt-in left
every check passing.

**Status.** Current

### Q2.227 — What splitting `busy` cost, and why the code stayed

**Question.** `ManagedSession.prompt` refused on one expression —
`this.turn !== null || this.clearing || this.restarting` — answering a single
`busy`. Taking a mid-turn message means one of those three stops being a refusal.
Is that a new arm or a new method?

**Decision.** Both, and the split is along the line the old expression blurred. A
`/clear` or a restart is the agent being **unaddressable**; a turn is the agent
**working**, which is the ordinary state somebody types a correction in. So
`prompt` keeps `busy` for the first two — with every assertion it had, including
`daemoncheck`'s that a prompt beside an in-flight clear still answers
`409 turn_in_flight` over HTTP — and answers a new `turn_in_flight` arm for the
third, which appends nothing and tells the route to go elsewhere.

**Why a second method rather than a branch.** `prompt` is synchronous by contract
and the contract is load-bearing: it answers a 202 carrying `{turn, seq}`, it calls
`safeAppend`, and its guard is an assignment made before any await. `Session.steer`
is an RPC. An await inside `prompt` would put a suspension point in front of the
one assignment every other guard in the class depends on. `sendMidTurn` is the
async half, and the route calls it only on the arm that says to.

**The precedent it follows.** `POST /sessions/:id/prompt` already waits where
`ManagedSession` refuses — `await managed.whenRestarted()`, with `daemoncheck`
pinning both halves: *"the session itself still refuses a prompt mid-restart"* and
*"but the route waits and sends it"*. This is the same division one state over.

**Status.** Current

### Q2.228 — Parking is advertised as lossless. Is it?

**Question.** Q2.224 shipped parking on the claim that *"the process goes; the
transcript, the `agent_session_id`, the worktree, the branch and the title do
not"*, and `.env.example` says the same thing in four words: *"the process is
killed; nothing else is"*. Somebody asked whether that survives an agent with
background work running. It does not.

**Measured 2026-09-11, the development machine, against `~/.reemoat/reemoat.db`
and the installed binaries.**

*The hazard is real and has already fired.* Five sessions carry `exit.reason =
"parked"`. One of them is `s_5d26f98e` — Q7.113's own measured session — released
at 17:34:25, **60 m 14 s** after its last event, against a saved
`machine_settings.idleReleaseMinutes` of 60. Nothing moved the idle clock in that
hour.

*Why `parkable` could not see it.* `status === "idle"` is honest for a session
whose turn has ended, and Q2.44's own rule is that *the turn ending is not the
agent stopping*. Background work is that rule's sharpest case: the daemon holds
`running`, `blocked`, `starting`, `stopping` and the terminal states, and there
has never been a state for *the agent handed something off*.

*What a park does to that work, traced link by link.* `stop("parked")` →
`doStop` → `Session.dispose` sends `session/cancel`, then `session/close`, then
`AcpClient.close`: stdin EOF, 3 s, **SIGTERM to the process group**, 3 s,
**SIGKILL to the process group**. Every Bash tool call the CLI makes is spawned
`detached: true`, i.e. `setsid()` — confirmed live, a background `sleep` ran at
`pgid == pid`, state `Ss`, parented to the CLI — so the daemon's group kill does
not reach it directly. The CLI kills them itself: its `SIGTERM` handler runs the
shutdown sweep, which group-SIGKILLs every backgrounded shell and records each as
`"stopped"` with its `toolUseId`. That record goes nowhere this daemon reads. On
the SIGKILL rung, and whenever the adapter dies outright, the shells instead
**survive as orphans** reparented to launchd, still writing to
`/private/tmp/claude-///tasks/.output`, with
nothing able to report or stop them.

*And nothing comes back.* `session/resume` replays no task state; the Agent SDK
states outright that the background-task set is per-process and that nothing is
emitted at startup; the adapter's `replaySessionHistory` has a subagent replay
pass and no async-task equivalent, and its only teardown is a bare `tasks.clear()`
that emits no terminal update. The one durable registry —
`~/.claude/jobs//adopt.json` — is gated on `CLAUDE_JOB_DIR`, which this
daemon does not set: `~/.claude/jobs` does not exist on this machine.

*Two partial mitigations already existed and neither is enough.*
`CEILING_PARK_FLOOR_MS` is two minutes on the **ceiling path only**, and its own
docblock concedes the gap — *"two minutes is not a judgement about background
work; nothing here can make one"*. And out-of-turn `agent_log`/`other` events move
`lastEventAt` without being logged, which landed 2026-09-10 inside a commit titled
*"legal docs added"* with no entry here at all. The 60-minute park above is the
measurement that it does not fire for a quiet agent.

**Driven against a real claude, 2026-09-11** — `pnpm harness --agent claude --raw`
under 2.1.268 / claude-agent-acp 0.73.0, three runs. What the wire actually does,
rather than what the adapter's source suggested:

- *The spawn is first and it is thin.* `async_task_spawned` carries `taskType:
"shell"`, `showInTranscript: false`, `canStop: true`, and `name` equal to
`description` — and **neither `outputFilePath` nor `toolCallId`**. Both arrive on
separate `async_task_progress` updates a moment later, so a fold that merged only
on the spawn would carry neither, ever.
- *The spawn precedes the lying card.* It lands **before** the Bash
`tool_call_update` that reports `status: "completed"`, and that update carries
`_meta.jetbrains.air = {version: 1, asyncTasks: {backgrounded: true}}` beside
`claudeCode.toolName: "Bash"` — the marker read as `ToolCallUpdateEvent.
backgrounded`, confirmed against real bytes rather than against the adapter's
`dist/`.
- *There is no heartbeat.* Both progress updates are correlation and arrive at
once; a `sleep 45` produced nothing further for its whole life. **That is the
measurement the staleness bound was waiting on, and it settles it against:** a
quiet task is indistinguishable from a stopped one by time alone, so a bound on
last-heard-from would kill quiet work and spare chatty work.
- *The end arrives during the turn, as two updates.* Backgrounding a `sleep 5`
inside a turn held open by a foreground `sleep 30`: `state: "stopped"` first —
the adapter closing a task it stopped seeing in the CLI's level — then `state:
"completed"` behind it. So **a terminal state is not final**, and a fold that
refused a second terminal word would label every finished shell `(stopped)`,
which reads as *somebody stopped it* about a build that succeeded.
- *The output path is what containment refuses.*
`/private/tmp/claude-///tasks/.output` —
outside the workspace, which is why there is no detail view to build and why the
panel's footer says so rather than leaving an absence unexplained.

**What changed underneath Q7.113.** That entry closed on one sentence: *"what
would close it is an ACP message for 'I am waiting' … neither exists, and neither
is ours to add."* The first of the two now exists, in the **pinned** adapter
(`claude-agent-acp` 0.73.0), and is one client capability away — three
`session/update` variants (`async_task_spawned`, `async_task_progress`,
`async_task_state_update`), an `AsyncTaskState` of five words with three of them
terminal, a stop verb `_session/async_task/stop`, and a marker on the detaching
Bash `tool_call_update` saying its card is not finished. All of it gated on
`clientCapabilities._meta.jetbrains.air = {version: 1, capabilities: ["asyncTasks"]}`,
which this client did not send.

**Decision. Declare the capability, refuse to park over live work, and draw it.**

1. **A live task blocks parking, with no timeout.** One clause in `parkable`,
placed with the two other clauses `status` cannot express — `clearing ||
restarting` and a non-empty prompt queue — because all three are *a session
that owes somebody something while `status` honestly reads `idle`*. The
ceiling inherits it through `parkCandidates` with nothing threaded, so at
`MAX_LIVE_SESSIONS` with nothing takeable `create` answers `429
too_many_sessions`: a session somebody does not get, so that a build somebody
is running survives.
2. **Claude only, and not even all of claude.** kimi backgrounds fully and maps
`background.task.terminated` nowhere, codex's `unified_exec` PTY outlives its
call with no push, opencode cannot background at all — and within claude the
adapter marks a backgrounded **subagent** `ignored`, which is Q7.113's own
measured case. So `CEILING_PARK_FLOOR_MS` and the stderr clock stay: they are
what stands for everything the clause cannot see, which is most of the fleet.
A margin bought for a case that is still real must not be spent because a
neighbour got a signal.
3. **The set rides the snapshot and is never logged.** `applyContextUsage`'s rule,
reached by a sharper road: everything that hits `record` moves `lastEventAt`,
so a logged lifecycle would defer the sweep **by accident** for a task that
chatters and not at all for a `sleep 600` — the guard would be strongest
exactly where it is least needed. It is fanned out with
`reportsBackgroundTasks` beside it, because an empty list from kimi means
*nobody asked* and an empty list from claude means *nothing is running*, and a
count has no spare value to say which.
4. **A stop clears the set and says so once.** `contextUsageState = null`'s
argument at its strongest: a parked session keeping the map would claim
`running` about process groups that are gone, on every snapshot, for ever —
verbatim the failure Q7.113 refused to ship a feature over. The sentence is
`dropQueuedUndelivered`'s precedent, one row for one act, and it says the work
was *still running* rather than that it was killed, because the SIGKILL rung
leaves orphans and this daemon watched neither.

**⚠ The blocker the plan did not predict, and it is worth the paragraph.** The
published SDK refuses these notifications, and no hook reaches the refusal.
`zSessionUpdate` is a closed `z.union` in both 1.3.0 and 1.4.0 with no arm for any
of the three, and **two** places parse it: `registerAppNotification`, which a
custom parser can replace, and `ClientApp`'s constructor, which installs a
`SessionUpdateRouter` parsing every `session/update` unconditionally. The second
is not reachable from any option — a client built with `acp.client()` cannot
receive one of these however it registers its handler, and the notification is
rejected `-32602` and logged below anything this daemon can see.
`AcpClient.splitAsyncTaskUpdates` takes those three off the byte stream before the
SDK reads it, and forwards everything else untouched so that every known variant
keeps the validation it has today. The hot path is **one `indexOf` per line** —
`usage_update` arrives on essentially every output token, so a `JSON.parse` per
line would have been a real cost. Found by declaring the capability and driving a
real notification through the driver's rig; reading the schema first would have
been the cheaper order, and that is the lesson rather than the fix.

**⚠ Two things gave a parked session away, and both were found by looking at the
screen rather than at a driver.** Q2.224 decided parking shows *nothing*, and:

- *The `/` menu was empty.* `doStop` withdraws the command list on every stop, and
point 7 of that entry had kept `agentConfigState` for a reason that applies to the
command list word for word — the process is coming back to the same conversation.
So the model picker worked and `/` opened nothing, under a composer whose
placeholder is literally `Type / for commands`. Measured on a real daemon: 111
commands live, **0** parked. It is kept now, with no revision bump, because the
list did not change; the resume replaces it through `applyAgentCommands` in the
ordinary way.
- *This feature's own new row.* The `error` a stop writes when it ends live
background work said *"when this session ended"* — and `doStop` is reached by
`daemon_shutdown` and by `restartAgent`'s `config_changed`, so a deploy or an
ultracode toggle wrote that into a conversation that had not ended. The noun is
the agent now, which is true in every arm, and a **park writes nothing at all**:
it should be unreachable (`parkable` refuses over live work), and the one way to
reach it is a guard that failed — which must not announce itself in somebody's
transcript.

**Alternatives taken out.**

- *A staleness bound on each task's own last update.* The elegant answer, and
unsafe on an unmeasured premise: if a quiet task emits no `async_task_progress`
the bound kills quiet work and spares chatty work, which is this entry's own
defect inverted. It becomes available the day the progress rate is measured.
- *A hard cap on how long background work may defer parking (~6 h).* Argued for,
and the argument is real — `MAX_LIVE_SESSIONS` only became a memory budget
because `idlepark.ts` bounds the population from the other end, so an unbounded
clause un-bounds it again at ~397 MB per pinned session. Declined on the owner's
word, because a cap with no measurement behind it is a number dressed as a
judgement and the asymmetry runs the other way: too large costs memory, too
small costs work. The seam is one constant beside `CEILING_PARK_FLOOR_MS`.
- *A manual lever — a pinned session never parks.* Works for all four agents and
needs no signal, and was declined because parking is deliberately invisible
(Q2.224 point 6) and a control that makes it visible is a decision about
housekeeping somebody cannot otherwise influence.
- *Declaring `nativeSubagentSessions` for symmetry.* It sets the adapter's
`forwardSubagentText`, which Q6.4 refused on budget — and a permission raised
inside a subagent is then addressed to the **child** session id, which
`AcpClient.route` answers `invalidParams` for. That is a subagent's approval
dying on the floor.
- *Reading the CLI's own task files.* Q7.113 rejected it and the rejection
stands: vendor private state at an undocumented path, and the path is outside
the workspace, which containment refuses anyway.

**Driven.** `daemoncheck.restart-and-resume.ts`: that the `_meta` this daemon
sends is exactly the AIR object, which is the one row with no second signal
behind it; the negative first, a session with nothing running still released
beside one that is not; a session with live work not released *at any age*; that
the refusal is the task rather than the fixture, by completing it and sweeping
again; each terminal word releasing and `paused` not; the ceiling refusing a
`create` rather than taking the agent, with the floor faked away so the refusal is
the task; the stop route's three answers with `stopped: false` a success; an id
the session never announced refused before the agent is asked; and that a stop
says what it was still running, once, and then claims nothing. Seven of them go
red under a one-line mutation of the clause. `webcheck`: the foot line over both
sources including the mixed-kind fallback and that a finished task is not counted;
the chip table as a total mapping over all five states with the three terminal
ones three distinct tones; the sections as a partition, an unknown kind included;
and the `backgrounded` fold surviving the completing update that follows it.
`pincheck`: the installed adapter's own `clientSupportsAirCapability` accepting
the literal this daemon sends, plus the negative that says the gate is a gate —
because `AIR_EXTENSION_VERSION` is module-private and there is nothing to compare
constants against.

**Status.** Fixed, 2026-09-11.

### Q2.229 — Parking is invisible for thirty minutes, and then a deploy gives it away

**Question.** Q2.224 shipped parking on the promise that a released session *"draws
as an ordinary `idle` session and says nothing"*, and `doStop` keeps
`agentConfigState` and `agentCommandsState` for `parked` alone so the controls and
the `/` menu stay live. Both are true of the process that parked it. Neither is true
of the next one: those two fields are in memory, `ManagedSession` deliberately
restores no config from disk, and a parked row therefore comes back with nothing.

**Measured, 2026-09-19**, on the development machine, read-only against the running
daemon. Five parked rows, two claude and three opencode. Every one of them answered
`GET /sessions/:id/commands` with `revision 0, dropped 0, count 0`, and carried
`agentConfig.options: []` on its snapshot. A freshly created claude session on the
same daemon answered `revision 1, dropped 0, count 111` with `context` among them,
four options — `mode`, `model`, `effort`, `fast` — and five modes including
`bypassPermissions`. So the two states are not a matter of degree: a parked session
is one deploy away from a composer with three `—` chips under *"The agent is not
offering this control at the moment"* and a `/` menu with nothing in it, and it
stays there, because nothing publishes again until somebody types. The prod hosts
update at 04:00 and 05:00 UTC, which makes that the state of every overnight
conversation, fleet-wide, every morning.

It also answers a question that was filed separately: **`/context` was reported as
"not published as a command"**, and it is published. The 111-command list has it,
and driving that list through the client's own `buildCommands`/`filterCommands`
ranks it **first** for the query `context` and shows it for `c`, `co`, `con`. What
the reporter had was a session whose agent was away. One defect, two symptoms.

**Decision.** Keep them, on a wider gate, and write them down.

`revivableByPrompt` — `autoResumable`'s `prompt` column, asked one step earlier
because `doStop` has the reason before there is an `exitRecord` to read it from — is
the single gate on three things now: what `doStop` keeps, what `configIsDeferred`
accepts a tap on, and what `persistedRow` writes to the new nullable
`sessions.agent_state_json`. **A call into that function and never a second
`switch`**, which is what keeps *"adding an `ExitReason` is a compile error"* true in
one place; `daemoncheck` asserts set equality between the two over the whole union
rather than listing the members, so a new reason lands in the sweep with nobody
adding a line.

That widens the keeping from `parked` to `parked`, `stopped`, `agent_exited`,
`agent_signed_out`, `daemon_shutdown`, `daemon_restarted` and `config_changed`, and
leaves `start_failed`, `start_timeout` and `agent_kill_failed` clearing as before —
where `—` is the honest reading, because there was never a conversation for a
control to be about. The argument was never about the word: a conversation that
comes back on a message is one whose controls still describe something.

**What makes a stale copy honest is that nothing in it reaches an agent unchecked.**
A wake replays it through `Session.restoreConfig`, whose two withdrawal guards skip
any option or mode the returning agent no longer offers — which is precisely the
risk `agentConfigState`'s docblock named as the reason not to restore from disk,
answered rather than accepted. The worst case is a control that takes a tap and then
quietly does not come back, which is the bound parking already had within one
daemon life.

**Four things that are easy to get wrong here, and what each cost.**

- **`commandsRevisionValue` seeds to 1, not 0.** `commandsPlan` in
`packages/web/src/store.ts` reads `0` or `undefined` as *"this daemon has
nothing"* and drops the fetch, so a restored list left at 0 would sit on the
daemon with the `/` menu still empty — the exact symptom, with the fix in place.
- **The raw `agentConfigState`, never `snapshot().agentConfig`.** That one is
composed through `withUltracode`, which rewrites the effort value to a choice no
agent ever published, and `dedupeAliasChoices`, which moves the model selection
off its placeholder. Replaying either sends the agent something it never said —
the same ⚠ `restartAgent` already carries about its own capture.
- **Refused whole past `MAX_AGENT_STATE_BYTES`, never clipped.** A clipped choice
list leaves `setConfigOption` validating against fewer rows than the agent
published, so a value somebody really can choose answers `invalid_value`: a
control that lies rather than one that is absent. 64 KiB, twice the measured
worst case — opencode's 362 models reduce to ~33 KB once the prose is dropped
from every unselected choice — and doubled resident rather than merely on disk,
because the blob rides `SqliteSessionStore.put`'s dirty-check key.
- **The `busy` guard moved above the deferred arm.** `restartAgent` reaches its
process boundary through `stop("config_changed")`, a reason a prompt revives, so
from the moment it stops `configIsDeferred` answers `true`. Recorded there, a
choice would be written into `agentConfigState` and then silently overwritten by
the `restoreConfig` already putting back a snapshot captured before the tap:
200, the chip moves, nothing happens. `clearing || restarting` is tested first
in both `setConfigOption` and `setMode` now, because in both windows the config
is about to be replaced wholesale and there is nothing a recording could be
recorded against.

**What the client changed: nothing.** `drawnControls`' first branch is
`live.length > 0` and it returns `stale: false`, so a session arriving with options
is already drawn live and tappable whatever its status — which is why the daemon's
two sets were made one set rather than a flag being added to the wire. That property
was asserted nowhere: every `stale` check in `webcheck` drives the *empty* branch,
where the status is exactly what decides, so re-narrowing the first branch to
`hasLiveAgent` would have left all of them green while the composer went faint on
four statuses at once. It is pinned by name now.

⚠ **One documented invariant is reversed and one window closes.**
`agentConfigState`'s *"deliberately not restored from disk"* now carries an
exception, stated at the field; and `snapshotConfigSource`'s *"the empty window is
left empty on purpose"* describes a window that no longer opens, since the restart
keeps its controls throughout. The gate below it stays: `armForStart` empties the
field on the way *in* to a spawn, so *"no live agent yet: report that rather than a
memory"* has more than one way of being true.

⚠ **That last sentence was wrong, and it was the gate's only surviving
justification.** `armForStart` assigns `exitRecord`, `parkedAtSignOut`,
`stopRequested`, `stopping`, `startAbandoned`, `startPromise` and `session` —
seven fields, and `agentConfigState` is not one of them. What the gate is worth is
narrower and still real: `held` is the *restart*'s captured config, and serving it
over a set `doStop` really did empty would report a memory where the rule is "no
live agent yet". `doStop` empties it for the three `revivableByPrompt` refuses, so
the clause still has a state to answer for. Corrected at the docblock 2026-09-19,
in the review that also found Q2.230.

**Status.** Fixed, 2026-09-19.

### Q2.230 — A wake now replays a mode, and one of the two callers was nobody

**Question.** Q2.229 made `doStop` keep `agentConfigState` for every stop a message
undoes and wrote it to `agent_state_json`, so `doResume`'s `wantedConfig` — empty
on all but a parked wake before — is now a real option list on essentially every
resume, and `Session.restoreConfig` replays it. Two things follow that nobody
decided: a tap landing *inside* that replay, and the boot pass running it with
nobody present.

**What was measured.** Both reproduced, 2026-09-19.

- **The tap.** `restoreConfig` runs *after* `onStarted` has published, so a
`setConfigOption` or `setMode` arriving in that window finds `exitRecord` cleared
by `armForStart` (hence `configIsDeferred` false), a live `session`, and neither
`clearing` nor `restarting` — a wake sets neither. It reaches the agent, answers
`ok`, and is then overwritten by the snapshot captured before it: 200, the chip
moves, nothing happens. That is verbatim the failure `restarting` was written
for, reached through the door Q2.229 opened. It was invisible because the *end
state* is identical either way — the assertion that the wake put back what it
captured passes with and without the bug.
- **The boot pass.** `shutdown` stops every live session with `stop("daemon_shutdown")`,
which `revivableByPrompt` accepts, so the config is kept, persisted and adopted;
`autoResumable(…, "boot")` is `true` for that reason, so the pass resumes the
session and `restoreConfig` re-applies the remembered mode with nobody watching.
On the prod hosts that is 04:00 and 05:00 UTC.

**Decision.** The tap is a defect and is fixed: `replacingConfig` names all three
windows — `clearing`, `restarting`, and `resuming` — and both methods test it
instead of writing two flags out by hand. The set was the thing that drifted, and
only `setMode` had ever been raced, so reverting `setConfigOption`'s half left every
driver in this repository green; `daemoncheck.restart-and-resume.ts` races both
inside a real wake now, through a rig hook that fires on the restore's own RPC.

The boot replay **stays**, on the owner's word. Restoring what somebody chose is the
whole of what Q2.229 bought, and a boot pass is not a new decision — it is the same
conversation coming back. What makes it bounded rather than a grant is
`restoreConfig`'s two withdrawal guards: a mode the returning agent no longer
publishes is skipped, which is what claude does with `bypassPermissions` under root.
Recorded here rather than left as a side effect, because *"the daemon re-applies a
permission mode at 4am"* is a sentence somebody should have written down before it
was true.

**Alternatives.** Skipping the mode on the `boot` trigger and replaying it only on a
prompt was offered and declined: it splits one restore into two behaviours keyed on
who asked, and the thing it protects against — a session left in a permissive mode
coming back in it — is a session the person put there. Refusing to restore a
full-access mode at all was declined for the same reason and a sharper one: it would
silently drop a choice somebody made by name, which is the failure Q3's plan-card
work is about from the other side.

**Status.** Fixed (the tap) and decided (the boot replay), 2026-09-19.

### Q2.231 — a turn the agent never answers, and the only thing in the process that can end one

**Question.** Reported from a live machine: the panel reads *working* hours after
the agent had finished. The owner's reading was that claude-agent-acp can start a
turn by itself on returning from background work, and that such a turn has no
`session/prompt` to produce a `turn_end` from.

**Decision.** A second sweep on `idlepark.ts`'s existing clock —
`SessionRegistry.abandonWedgedTurns`, the predicate `ManagedSession.wedged`,
`TURN_SILENCE_MS` at an hour, `REEMOAT_TURN_SILENCE_MINUTES` to move it and `0` to
switch it off. It calls `Session.abandonTurn`, which ends the turn **locally** with
`turn_end{stopReason: "abandoned"}` and sends the agent nothing at all.

**The reported mechanism is inverted, and that matters for anyone chasing this
again.** Nothing but `armTurn` writes `ManagedSession.turn`, and `armTurn` is
reached only from the three prompt paths — so a turn the agent starts by itself
leaves `turn === null`, and `status` reads **`idle`**, not `running`. Its events are
not lost; `startIdleDrain` records them. That produces the *opposite* defect, which
`sendMidTurn`'s `started_new_turn` arm already warns about.

**What actually pins `running`.** `status` is derived and `running` is
`this.turn !== null` and nothing else. `turn` is cleared in exactly one place,
`pump`'s `finally`, reached only when the turn's generator returns, which happens
only on a `turn_end` or an `error` — both produced only by the `session/prompt`
request settling. And that request is the one RPC in `session.ts` fired with **no
deadline**, deliberately, because a turn may legitimately run for hours. So
`status === "running"` is exactly *"a `session/prompt` this daemon issued has not
settled"*, and an adapter that stops answering pins it for the life of the process:
`POST /cancel` observes the same unsettled promise through `waitForTurnToSettle`,
and `parkable`'s first line refuses anything that is not `idle`, so the sweep, the
ceiling's eviction and a wake all skip it at any age — while it holds one of
`MAX_LIVE_SESSIONS` and its agent's ~397 MB. Only `DELETE /sessions/:id` or a
restart cleared it.

⚠ **`withAbandonableDeadline` is the obvious fix and it is the wrong one, twice
over.** Its own docblock records that against a peer which never answers the
cancellation reclaimed nothing — `pendingResponses` stayed at 20 of 20 — so it does
not solve the residual it exists for in exactly this case. And it names
`session/prompt` as the one method whose `ctx.signal` an installed adapter honours:
across codex-acp 1.8.0's whole bundle `ctx.signal` appears once, on that method. So
the "deadline" would abort the agent's work — a third stopping verb arrived at by
accident, against *"stopping the agent and stopping the session are two verbs"*
(Q2.42) and against *"the agent must never notice a client leaving"*.

⚠ **`turnActive` has to be cleared by hand, and missing that would have been worse
than the bug.** It is `Session`'s guard against two prompts in flight and it is
cleared *only* inside the outstanding request's callbacks. A turn closed without
those running reads as idle, opens the composer, accepts the next message and then
throws *"a prompt is already in flight for this session"* into the transcript — for
every message, for the rest of the session. `abandonTurn` clears it itself.

⚠ **And the late answer had to be fenced, or it would cut a *live* turn short.**
The request stays outstanding and may settle at any time, including after a second
turn has started. Every callback it installs is now fenced on a `promptEpoch`
`abandonTurn` bumps, so a stale answer pushes no second `turn_end` for the prompt it
belonged to and — the sharper half — cannot end the turn running now. The driver
walks exactly that: abandon, then answer the stalled request, then assert the live
turn is still live.

**Why silence rather than duration.** A turn running for three hours while the
agent narrates is working; a turn that has produced nothing is not distinguishable
from a dead one. A session waiting on a person reads `blocked`, which the predicate
refuses through `status` rather than through a clause; `hasLiveBackgroundWork` is
Q2.228 applied to the other threshold.

⚠ **The threshold was an hour and both halves of that were wrong — the number and
the clock it measured.** It was reasoned rather than measured: what goes quiet
inside a turn is one long tool call, a build or a test suite, and an hour is past
all of those. That is a fact about the wrong kind of turn. The correction came from
the machine that filed the report, whose store still held the session
(`s_89d35945`, 2 203 events): a prompt at 03:11:07 answered by a **real**
`turn_end{end_turn}` from the agent at 04:39:26 — 88 minutes, working the whole
time — and inside it a single silence of **51.7 minutes**, seq 426 → 427, with 21.8
minutes the next largest. An hour cleared that by 8.3 minutes, which is a
coincidence and not a margin. ⚠ Both gaps are between *agent* events, the series
the predicate measures; swept over every event the second reads 21.5 minutes
instead, because a person's prompt landed inside it (seq 1509 → 1510). The largest
is 51.7 either way.

So the number is now a multiple of the one measured silence rather than a margin
over it: **three hours**, ~3.5×. The multiple comes from the asymmetry, which is
one-sided. Ending a turn that was not over is not recoverable the way the other
mistake is — the transcript says the agent stopped answering where it had not, the
real end's `stopReason` and `usage` are dropped, and the next message reaches an
agent still answering the last one. Waiting too long is the status quo this fixes,
bounded instead of infinite. ⚠ It is no longer derived from `IDLE_PARK_MS`: "twice
the park threshold" was arithmetic dressed as an argument, and the two answer
different questions on different evidence.

⚠ **And the clock had to become the agent's own.** `wedged` measured
`lastActivityAt`, which every write moves — `status` events, the daemon's errors,
and the *person's* messages, since `recordPrompt` appends through `safeAppend`. So
somebody typing into a session that says *working* reset the silence clock on every
message, and the one state this daemon cannot otherwise escape was kept alive by
the person trying to escape it. The same measured session shows three such prompts
inside the open turn (04:28:35, 04:32:16, 04:38:44). `lastAgentEventAt` is set only
from `record` — the pump's loop and the idle drain, i.e. what came out of the agent
— and from the drain's early return for the `agent_log`/`other` it drops, because
those are the agent speaking even when they are not worth logging. The two clocks
stay separate rather than becoming one field: for *parking*, a person typing **is**
activity and is the reason not to take the agent away.

⚠ **The driver row for that clock passed with either field, and the reason is
worth keeping.** The two clocks are milliseconds apart in a test, so no `now` handed
to `abandonWedgedTurns` discriminates them — the row was written, the wrong field
was restored to check it, and it printed `ok`. It is a pair now: the mechanism
asserted with no clock at all (a person's message moves one field and not the
other) and the outcome asserted at *exactly* the threshold, with 200 ms of declared
margin either side of the instant it is measured from. A minute of slack — which is
what the row carried at first — swallows the difference and asserts nothing.

⚠ **Two of the driver rows written for this passed for the wrong reason, and both
are the same class of mistake as the bug.** *"Nothing was sent to the agent"* was
asserted as `stalledCount() === 1` — which says only that the outstanding prompt is
still outstanding, and is true however much traffic goes the other way: adding a
`session/cancel` to `abandonTurn`, the third stopping verb this entry exists to
avoid, left the whole section green, because the rig dispatches on the method, a
notification carries no id, and its `default:` arm drops one without a word. The rig
records every inbound method now and the property is a list rather than a count. And
the 61-minute row measured against the fixture's `now`, stamped when module 1 of 23
was imported, while `wedged` measures the real `turnStartedAt` — an undeclared
60-second wall-clock budget on a driver that has no other one, which a slower runner
or one more section inserted above would have turned red, reading as the feature
being broken rather than the clock. The instant is taken in the section now.

**What this deliberately does not do.** It adds no `SessionStatus` member and holds
no turn open. It does not stop the session, which would have read as `parked` or
`stopped` for a conversation nobody ended. After the ending the session is `idle`,
so the ordinary sweep releases the wedged agent half an hour later — the code that
could not see it before — and the pending request goes with the process. The wire
change is one `TurnStopReason` member and the daemon ships first: `wire.ts` types
`stopReason` as `string` and `stopReasonText` already falls through for a value it
has never heard of.

### Q2.232 — a question the agent asks between turns is cancelled the instant it arrives

**Symptom.** Reported by the owner from session `s_078b731c` on their own machine:
questions to them kept arriving already cancelled — *"cancelled — no turn to answer
into"* — and the first plan approval was drawn *"Approve Plan — denied, no turn to
answer into"*. His requirement, verbatim in substance: all such requests must wait
until somebody answers them.

**Measurement.** Read-only, the reporting machine's `~/.reemoat/reemoat.db`, session
`s_078b731c`, claude under claude-agent-acp 0.73.0. `turn_end` at seq 411
(13:50:00); the next `prompt` is seq 860 (14:28:12). Between them the agent worked
with no prompt: 446 events from 13:59:27, beginning after a background workflow
finished. At seq 511 (14:00:42) it raised an `AskUserQuestion` elicitation and seq
512, stamped the same second, is `elicitation_resolved {action: "cancel", by:
"no_turn"}`. At seq 685 (14:27:48) an ExitPlanMode `permission_request` titled
*Approve Plan*, and seq 686 the same second, `permission_resolved {outcome:
"cancelled", by: "no_turn"}`. Again at 1967/1968 (16:31:18), an elicitation, after
the turn that ended at seq 1652 (15:12:36). Each time the person had to prompt
again (seq 860, seq 2049) to be asked the same thing inside a turn, where it was
answered (864, 2053, `by: "client"`). Across that store's 20 sessions: 3
`no_turn` resolutions, all this session, none `turn_ended`.

**Cause.** Two settle paths keyed on turn boundaries, both older than the idle
drain. `ManagedSession.refusalReason` answered `"no_turn"` whenever `this.turn ===
null`, so `resolvePermission` and `resolveElicitation` recorded a refusal and
answered the agent `cancelled` on arrival. It dates from the initial commit, when
events outside a turn were stranded in the queue (Q2.44) and nobody *could* see the
request — refusing then was the honest answer. Q2.44 fixed the stranding and left
the refusal behind it. The second path is the same judgement one step later:
`pump`'s `finally` called `sweepPending("turn_ended" | "pump_failed")`, settling
any request still parked when a turn ended.

**Decision.** A request the agent raises is settled by exactly four things: a
person's answer, a person's cancel (the card's ✕, or Stop), the agent withdrawing it
(the abort signal, `agent_withdrew`), and the agent going away (`doStop`,
`session_stopped` — a stop, an exit, a restart). Never by a turn boundary, never by
a timer. `refusalReason` keeps only the terminal arm; `pump`'s sweep is deleted.
`turn_ended`, `pump_failed` and `no_turn` stay in `AnswerResolvedBy` — stored logs
hold them and `resolvedByText` still draws them — and nothing writes them.

**Consequences walked.**
- *Status.* A request parked with no turn reads `blocked`, which it already did
(`awaitingCount` precedes `turn` in `status`). `parkable` and `wedged` both read
`status`, so neither the idle sweep, the ceiling's eviction nor the silent-turn
sweep touches it.
- *Stop.* `cancelTurn` with no turn but a request parked used to answer `no_turn`
and leave it, so the only way to dismiss it was the card's ✕. It now runs a turn's
own order — send `session/cancel`, sweep `turn_cancelled`, watch — and answers
`cancelled: true, turn: null` (`cancelWithoutTurn`). `CancelResult.turn` widens
to `number | null`; the route already typed `turn` as nullable. The sweep is
fenced on `turn === null`, as the turn's is on its own turn.
- *Revising a plan.* The composer's `revising` send is cancel-then-prompt. With no
turn the cancel used to be `no_turn`, leaving the plan parked and the new prompt
queued behind it in claude's FIFO — a message that never arrives while the plan
waits. The cancel now dismisses it, then the prompt is an ordinary turn.
- *`/clear`.* `clearContext` refuses (`409 turn_in_flight`) while a request is
parked with no turn, the same reason it refuses mid-turn: clearing decides what
happens to a cycle in progress, which is Stop's to decide. The composer's
`clearRefused` reads `canCancelTurn` rather than `turn`, so the refusal is drawn
rather than toasted.
- *The client.* The ask card was never gated on a turn. `canCancelTurn` widens to a
parked request with no turn, so Stop is offered there.

**What was not done.** No timeout on a parked request, in either direction — a
question may wait overnight. No re-ask machinery: a request the daemon refused is
gone from the agent's side, and the agent re-raises it if it still wants it.

⚠ **A plan raised between turns is offered no clearing grant.** claude-agent-acp
0.73.0 cannot carry out a plan approved *with the context cleared* outside a turn:
that choice answers `deny, interrupt: true` and records
`pendingExitPlanContextReset`, the restart it defers to sits below the
`isAutonomousResult` early `break` in the adapter's `result` case, and
`continuePlanInFreshContext` throws *"Cannot clear context without an active ACP
turn"* — read off the adapter's source, not driven with a real CLI. Pressing the
card's filled primary (Q3.594) there would stop claude with nothing continuing. So
`PendingPermissionSnapshot.outOfTurn` records whether a turn was held when the
request was raised, and `planControls` given `true` drops the shape's `clearing`
grant and fills the one left; the 0.63.0 shape has none and is drawn unchanged. An
older daemon sends no field and gets today's card. Declining with a reason is still
the message box, and a plan re-raised inside a turn gets both grants back.

**Status.** Current. Reverses the initial commit's out-of-turn refusal and the
turn-end sweep. Amends Q3.594: between turns the plan card draws one grant.

### Q2.233 — the agent working outside a turn reads as working

**Symptom.** Reported by the owner: after a background workflow finished, the
working line at the foot of the conversation did not appear although the agent was
visibly doing things — and *the working line means literally that the agent is
working*, which the owner called an invariant. Q2.231 had already named the mechanism from
the other side: a cycle claude starts by itself leaves `turn === null`, so `status`
reads `idle`.

**Measurement.** The same store as Q2.232. Out-of-turn agent content — `text`,
`tool_call`, `tool_call_update`, `plan`, a request — between a `turn_end` and the
next `prompt`: 1 194 events in 3 sessions, **all claude**; the byo, grok, kimi and
opencode sessions there have none. In `s_078b731c` two such stretches run 28.5 and
54.9 minutes. Their longest gaps, 24.1 and 50.4 minutes, sit *between* cycles, not
inside one: seq 573 is the agent writing *"I'll continue when the notification
comes"*, and seq 574 is the next cycle starting. So a clock over output cannot tell
a working agent from a waiting one, which rules out a timer as the primary signal.

**The adapter, read (claude-agent-acp 0.73.0, `dist/acp-agent.js`).** A result
whose `origin.kind` is in `AUTONOMOUS_RESULT_ORIGINS` (task-notification, peer,
coordinator, observer, observer-activity) is an autonomous cycle's end. Every
`result` — the user's own too — is followed by a `usage_update` whose `_meta` carries
`"_claude/origin": message.origin`, sent whenever the consumer has seen a top-level
assistant message (`lastAssistantTotalUsage !== null`), and sent *before* the
`session.cancelled` check. The SDK's `session_state_changed` running/idle is not
forwarded. `cancel()` calls `query.interrupt()` whether or not an ACP turn is active,
so `session/cancel` with no prompt in flight interrupts an autonomous cycle.

**Decision.** Work between turns is a state, not a clock. `Session` lights
`unpromptedSince` when the agent's own text, thought, tool call, tool update, plan,
permission or elicitation arrives with no `session/prompt` in flight — at arrival,
in `onUpdate`'s order, so a drain running behind the end marker cannot light it
again. A subagent's step (a non-null `parentToolCallId`) is a delegation and lights
nothing. What ends it:
1. a `usage_update` carrying `_claude/origin`, of **any** origin — one cycle runs at
a time, so whichever ended, the agent is between cycles (`marksCycleEnd`);
2. the agent answering a prompt of ours — claude runs its input FIFO, so every
cycle begun before that prompt has ended;
3. a `/clear`, whose old conversation's marker is unroutable;
4. the process going (`doStop` drops the mirror);
5. the silent-turn clock (below).

`ManagedSession` mirrors it, `status` reads `running` over it, and the snapshot
carries it as `unpromptedSince`.

⚠ **Latched on the first marker.** Tracking starts only once the agent has sent one
`usage_update` with `_claude/origin` — claude's first result does. An agent that
never sends one is never tracked, so a straggler after another agent's turn cannot
light a working line nothing would ever end. That is a capability read off the
agent's own output, not its name.

**Q2.44's refusal, re-read.** It refused three things. A new `SessionStatus`: still
refused, `running` is reused. A clock in `status`: still refused — this is a state an
event sets and an event clears. Widening `showsWorking`, *"because it is what refuses
Send"*: no longer true. `sendRefused` is `session.status === "stopping" ||
(!acceptsMidTurn(session) && (blocked || working))`, and a daemon that sends
`unpromptedSince` sets it only from a live agent, whose snapshot always carries a
`midTurnDelivery` — `daemoncheck` asserts the pair. A message sent now is an
ordinary `prompt`, which claude queues behind the cycle.

**What reads it.** `parkable` refuses it through `status` (the idle sweep would
otherwise release an agent mid-cycle once its output went quiet for half an hour).
`takesCredentialChange` refuses it (a credential change restarts the agent).
`clearContext` refuses it. `wedged` now tests `turn` itself, since `running` no
longer implies one. Stop is offered and works: send, no sweep of anything but
parked requests, and watch `awaitUnpromptedEnd`; `cancelRequestedAt` is set for it
and cleared when the work ends. ⚠ `armTurn` clears `cancelRequestedAt`: an
out-of-turn cancel the agent has not finished answering would otherwise make
`pump`'s cancel-before-prompt check end the *next* message unsent — exactly the
revising flow's cancel-then-prompt when the plan was raised outside a turn.

**The safety net, and why it is the silent turn's.** An agent that marks cycles and
then stops marking — an adapter change, an interrupt that pre-empts the result —
would read as working until the next turn ends it. `abandonWedgedTurns` also calls
`unpromptedGoneQuiet`, the same predicate as `wedged` (`status === "running"`, not
mid-clear or restart, no live background work, the agent's own clock) floored at
`unpromptedSince`, with `TURN_SILENCE_MS` and `REEMOAT_TURN_SILENCE_MINUTES` — three
hours by default. The evidence is the same with or without a turn: the agent has
said nothing. A separate, shorter number was rejected: the measured gaps above show
a waiting agent and a working one look alike to a clock, and a second number for
one judgement drifts. It writes nothing — no turn ended — and never settles a
request: a session waiting on a person reads `blocked`, which the predicate refuses.

**Rejected.**
- *Holding the turn open over the cycle* — Q2.44's objection stands: `canCancelTurn`
true for a turn that ended, `409 busy` for ever.
- *A timer after the last output as the primary signal* — the measured 50-minute
between-cycle gaps make any timer either lie during them or drop the line during
a long tool call.
- *Recording the marker as an event* — one row per cycle for something nobody did;
it rides the snapshot like `cancelRequestedAt`.
- *Keying on the agent id* — the latch reads the agent's own output instead.

**Compatibility.** `unpromptedSince` is optional in `wire.ts` and absent reads as
not working, which is today's behaviour. Daemons ship first. An older client
against this daemon sees `status: "running"` with `turn: null`: a running dot in the
list and no working line — degraded, not broken.

**Status.** Current. Narrows Q2.44 and closes the defect Q2.231 described from the
other side.

### Q2.234 — Finished background work belonged to the process, and an effort change took it away

**Symptom.** Reported by the owner, translated: *"After changing effort from
ultracode to high, all finished background tasks were reset, although it's the same
dialog. They must be kept."*

**Measurement.** Read-only against the development machine's store, 2026-09-24.
Session `s_078b731c` (claude, now `ultracode = 0`) launched six workflows in the
background between 13:39 and 15:38 — every one is a `Workflow` tool call whose
result reads *"Workflow launched in background. Task ID: w…"* (seq 147 → 1711). At
16:31:35 seq 2041 is `status interrupted`, `exit.reason: "config_changed"`, then
`starting`, `agent_config`, `idle` and a `session_started` on the **same**
conversation, all within one second. There is no `stoppedWithBackgroundWork` row
beside it, so nothing was running: every row the panel held was finished, and every
one was gone after that second.

**Cause.** Choosing a level while ultracode is on is `setConfigOption`'s ultracode
arm → `applyUltracode(false)` → `restartAgent` → `stop("config_changed")` and
`resume()` on the same `agentSessionId`, because ultracode is read only when a
conversation opens (Q2.43). `doStop` then set `backgroundTasksState = []`, and
`onStarted` handed the list to `applyBackgroundTasks`, which **replaced** it with
the new `Session`'s — a fresh `asyncTasks` map, empty. Nothing could refill it:
claude-agent-acp 0.73.0 holds the lifecycle per process in `AsyncTaskRuntime`
(`async-tasks.js`), built per session at `acp-agent.js:1377`, and
`teardownSession` calls its `clear()` without publishing anything; the SDK's
replace-semantics level (`backgroundTasksChanged`) *"does not create unknown
tasks"*. So the daemon was the only thing that had ever known about that work, and
it threw its copy away. The same `doStop` runs for a credential restart
(`applyCredentialChange`, `onAuthFailure`), a park, an agent exiting and a clean
daemon shutdown — all of them stops a message undoes, all of them the same
conversation, and every one lost the rows. An effort change *without* ultracode,
a model change and a mode change go through `session/set_config_option` and never
restarted anything; they were not affected.

**Decision.** A task list belongs to the conversation, not to the process.

- **Kept on Q2.229's gate.** `doStop` keeps the rows as `earlierTasks` whenever
`revivableByPrompt(reason, …)` — the same call that keeps the controls and the
`/` menu — and `applyBackgroundTasks` merges the live agent's list over them
(`withEarlierAgents`). The live agent's row wins an id it shares, which would only
be a reused id; the cap stays `MAX_TRACKED_ASYNC_TASKS` over both together, and
what gives way is an earlier agent's oldest-finished row, which is the order the
cap already evicted in. A `/clear` is a new conversation and drops them in
`clearContext`; a stop nothing revives (`start_failed`, `start_timeout`,
`agent_kill_failed`) drops them as it drops the controls.
- **A row that was running when its agent went reads `stopped`, with `endedAt` the
stop's time.** It cannot stay `running`: the process that owned it is gone and no
resume replays it (Q7.113), a live row makes `hasLiveBackgroundWork` refuse
parking and the silence sweep for ever, and the panel's clock would tick for ever.
`failed` draws `(error)` in the danger tone and claims the task itself went wrong,
which nobody measured. `stopped` is the chip for *ended from outside*, and it is the
adapter's own word for the same fact: `taskState` maps `killed` to `stopped`, and
`finishLifecycle` publishes `stopped` for a cancelled stream. The transcript's
existing `stoppedWithBackgroundWork` row still says it in prose, once.
- **Durable across a clean restart, with no migration.** The finished rows ride
the `agent_state_json` blob Q2.229 added, as a `tasks` key, written on the same
gate. A JSON key is additive in both directions: an older build's `toAgentState`
destructures `config` and `commands` and never reads it, and a blob an older build
wrote has none and reads as no rows. They are bounded **apart** from the controls
(`keptOnDisk`, `MAX_KEPT_TASKS_CHARS` = 32 KiB, rows kept whole, oldest-finished
first), because the controls are refused whole past 64 KiB and a long task list
must never cost somebody their model picker. Read back **row by row**
(`readKeptTask`): a row this build did not write — live, unstamped, over a bound —
is dropped alone, and a `tasks` that is not an array costs the tasks and never the
controls beside it.
- **A memory of tasks alone does not seed the commands revision.** Restore set it to
1 for any stored memory, which was right while a memory implied a list; 1 over an
empty list tells every client to fetch one. It is seeded only when there are
options or commands.

**What the client needed: nothing, and why that was checked rather than assumed.**
An agent swap walks `interrupted → starting → idle`, and `backgroundReporting` is
`unasked` for the first two. `showFinished` is `reporting === "reports" ||
finished.length > 0`, so the band is held open by the rows the daemon kept, not by
the arm — `FinishedSection` stays mounted and its fold stays where the reader left
it. The hidden set is keyed by session, the ids do not change, and
`forgetHiddenFinished` has one caller, `forgetSession`, so a reader's clear
survives the swap too. `webcheck` pins all three by name now, because each looked
like it could be tidied into the bug.

**What was not done.**

- **A crash still loses them.** The blob is written at a stop, as the controls are,
and a live session's row carries none. A column of its own written on every touch
(`background_tasks_json` through `migrate()`) would have survived a crash, and was
declined: it is up to 32 KiB re-serialized on every touch of every live session to
cover a daemon killed hard, and a column an older build does not know is one its
upsert leaves stale — so a roll-forward after a rollback could list rows from
before a `/clear` the older build performed.
- **The `unasked` sentence is unchanged**: *"It is not kept across a restart"*
remains true of running work and of a crash, and is shown only when there are no
rows, which is now rarer. Its wording is the owner's to revisit.
- **The empty band still flickers for a second.** A session in the `reports` arm
with **no** finished rows draws `Completed (0)`, and for the second a swap takes
it draws the `unasked` sentence instead. Nothing is lost — a zero band is a
heading with no fold — and holding the arm through the window would need a wire
field saying *restarting*.
- **A stop pressed on an earlier agent's id is still forwarded** to the live agent,
which answers `stopped: false`, already an ordinary 200. The panel offers no stop
on a finished row, and every earlier row is finished.

**What still loses them**, exactly: a daemon crash; a `/clear`; a stop nothing
revives; eviction at the 32-row cap; the disk budget on a clean restart; the
startup prune taking the whole session (Q2.222); and a rollback to a build that
rewrites the blob without the key. The budget was measured rather than guessed: a
row shaped like one of `s_078b731c`'s workflows serializes to 542 characters, so all
32 fit in ~17 KB and it never bites; a row at every text bound is 3 201, and 32 of
those keep the newest 10.

**Pinned.** `daemoncheck.restart-and-resume.ts`: a replacement through
`applyCredentialChange` — the door ultracode takes — keeps two finished rows and
turns the running one `stopped` with an end of its own; the finished row's end is
not restamped; the new agent's rows merge live-first; earlier rows hold nobody back
from release; a park keeps all four and writes them; a second registry over the same
store lists them on a `parked` row before any agent is back, at commands revision 0;
a wake keeps them; a `/clear` drops them; `start_failed` drops them; and the merge,
the cap, the disk budget and the reader as functions.
`daemoncheck.after-the-turn-and-config.ts`: the reported path itself on the modal
rig — a workflow completed under ultracode, then `effort: "high"`, still listed.
`daemoncheck.store-and-worktrees.ts`: the SQLite round trip, a live row dropped
alone, and a malformed `tasks` costing nothing else. ⚠ **Two rows pinned the old
behaviour** — a released session's list and a stopped session's list, both `[]` —
and are rewritten in place with a comment saying what they were. Each new guard was
knocked out once and its rows went red: the keep in `doStop`, the `stopped`
relabel, the `/clear` drop, the write in `persistedRow`, the revision gate.

**Status.** Current. Amends Q3.633: a zero is no longer what an agent swap leaves.

### Q2.235 — grok's questions, plan approvals and MCP forms arrive as its own requests, and are routed onto the two doors every agent uses

**Symptom.** Reported by the owner with grok 1.0.40: the agent called its
`ask_user_question` tool and the transcript showed the tool failing with *"Tool
`ask_user_question` failed: Failed to reach the client for user question: "Method
not found": _x.ai/ask_user_question"*, over a card header reading *"Ask: Какой
напиток ты бы выбрал прямо сейчас?"*.

**Cause.** `AcpClient` registered no handler for any `_`-prefixed method, so the
SDK answered every agent-to-client extension request `-32601`. grok sends three —
its question, its plan approval and an MCP server's form — and Q6.113 measured what
each did with the refusal: the question tool failed; the plan approval failed as
*"the client disconnected"* and **ended the turn**; the MCP server was handed a
`cancel` it never learned the reason for.

**Decision.** Parse each in `src/acp/xai.ts`, the one module that knows their
shapes, and route it onto a door every agent already uses, so parking, the log, the
card, Stop, the idle sweep and the four ways a request ends (Q2.232) are the
existing ones rather than a copy:

- `_x.ai/ask_user_question` becomes an elicitation built in **claude-agent-acp's
AskUserQuestion bridge shape** — `question_` with the options as a titled
`oneOf` (or an `anyOf` list for `multiSelect`), and its own-answer box
`question__custom` marked with `_askUserQuestionCustomAnswer`, the marker that
bridge documents as *intentionally agent-neutral, for other AskUserQuestion
bridges*. It then goes through `toElicitationForm`, so every elicitation bound is
the bound — twelve questions is twenty-four fields, the cap — with no second
number. The card draws it exactly as it draws claude's: a question a step, the
descriptions, the box and circle marks, the own-answer row. The answer goes back
as grok measured accepting: `{outcome: "accepted", answers: {:
label | [labels] | typed text}}`, a typed answer winning over a pick as on claude.
- `_x.ai/exit_plan_mode` becomes a **permission** titled *Approve plan* with
`rawInput: {plan}` — which is where the card reads a plan — and two options named
by the outcome each sends, `approved` (*Approve plan*, `allow_once`) and
`abandoned` (*Abandon plan*, `reject_once`). grok's `exit_plan_mode` tool call
carries `{}` for arguments and the snapshot clamps a permission's blob at 8 KiB,
so the plan is also written onto grok's own call as a `tool_call_update` with
`rawInput.plan`: the card recovers a clamped payload from the log, which would
otherwise hold no copy.
- `_x.ai/mcp/elicit` becomes an elicitation of the server's own schema, its message
prefixed with the server's name as grok's own card names it, answered `{outcome:
"accept", content}`, `{outcome: "decline"}` or `{outcome: "cancel"}`.

**What this costs in meaning, stated.** On grok **decline and cancel are one word**:
the question's only no-answer outcome is `cancelled`, which the model reads as
*"User declined to answer"*, so Skip and the ✕ send the same thing where on claude
they are two acts. `chat_about_this`, `skip_interview` and `annotations` exist on
the wire and are never sent, because nothing on the card asks for them. A plan's ✕,
Stop and every sweep send `cancelled`, which grok reads as *"the user wants to
revise the plan"* and stays in plan mode — exactly what the composer's `revising`
send (cancel, then the correction as a prompt) wants.

**The question is the title of its field.** grok has no short header, and the
title is what `renderAnswers` logs an answer under; without one a typed answer — which
`answeredQuestions` cannot join back by label — was logged as `question_0`. The
card draws no heading equal to its title (`askTitle`), so nothing is drawn twice.

**A plan's options keep their names on the card.** `optionLabel` substitutes a
kind's word whenever kinds are unique, and grok's two would have read *Allow once*
and *Deny* over approve and abandon. It takes `plan` now: a kind's word describes a
grant, and approving a plan is not one. `planControls` still curates claude's shapes
alone — grok's request has no `switch_mode` and matches none of them.

**grok withdraws by resolving, never by cancelling.** It sends
`_x.ai/session_notification {update: {sessionUpdate: "interaction_resolved",
tool_call_id}}` after every answer *and* after its own timeout, and no
`$/cancel_request` ever. `Session.withdrawable` gives each request a signal that
either the SDK's or that notification aborts, so the registry settles it
`agent_withdrew` — Q2.232's third way. ⚠ **The notification handler's position is
load-bearing.** grok resolves its own permission step for a call immediately before
it asks the question on that call; the SDK walks a message through the handlers
with one `await` each, so registered after the request handlers, that earlier
resolution reached its handler *after* the later question reached its own and
withdrew it on arrival — the Q2.232 defect again, by a new road. The driver
reproduced it before the handler moved to second place; it sends the pair in
grok's order.

**grok's own question timeout is off at the spawn.** `GROK_SPAWN_ENV` carries
`GROK_ASK_USER_QUESTION_TIMEOUT_ENABLED=false` on the grok arm of `resolveAgent`:
the default gives up after 30 minutes and answers itself "declined" (Q6.113), which
is Q2.232 from the other side. The environment outranks the user's `config.toml`
and loses only to an organisation's `requirements.toml` — which is what the
withdrawal above is for.

**With questions off, the tool is withdrawn.** grok keeps `ask_user_question`
whatever the client declares, so `REEMOAT_ELICITATION=0` now also sends
`_meta.askUserQuestion: false` on `session/new` (`sessionMetaFor`, measured to
remove the tool), and the question and MCP-form methods still answer `-32601`, as
`elicitation/create` does when declined. A plan is a permission and is always asked.

**Refusals.** Malformed params are `-32602` from the parser, before anything is
parked or logged. A question longer than the card's 4096-character message cap is
refused rather than drawn cut, because its text is the answer's key. `url` mode is
refused as Q2.20 refuses it; grok hands its MCP server a `cancel` for any refusal.
Every other `_` method — including x.ai's own `folder_trust/request` — is still the
SDK's `-32601`: an unknown request must stay a failure the agent reports.

**Rejected.**
- *Recognising grok's tool calls in the transcript and asking from those* — the
request is the protocol; a tool call is a picture of it.
- *A grok-specific card* — two bodies already exist and grok's requests fit them.
- *Sending grok's `revise` with the composer's text as `feedback`* — measured to
work (*"The user wants to revise the plan. The user said: …"*), and it would skip
the cancel; but it needs a route the composer does not have, and the cancel-then-
prompt that works for claude works here.
- *Handling `interaction_resolved` by diverting the line below the SDK*, as the
async-task updates are — it would order the notification strictly, but at the
price of a second parse of a stream that carries one notification per token.

**Status.** Current.

### Q2.236 — How does one session's agent reach another session's?

**Decision.** Through an MCP server this daemon injects into every agent that
declares an http MCP client, named `reemoat`, with two tools: `list_agents` and
`send_message` (three until Q2.243). `SessionOptions.mcpServers` is a callback called
after `initialize`, because `mcpCapabilities` is only known then, and `launchOptions`
hands it to `session/new`, `session/resume` and the `/clear` path alike.
`PeerMcpEndpoint` is its own listener on `127.0.0.1` with a port the OS picks, and
`PeerHub` is the one place every peer message passes through.

**Why MCP.** ACP has no notion of another session, and an agent can only be handed
a tool it calls through MCP; Claude Code's own cross-session SendMessage and
Codex's `send_message` are built-in tools for the same reason, and the one ACP host
that already does this (Paseo) injects an http MCP server exactly so. What an agent
sends arrives as a `prompt`, through the prompt route's own machinery (Q2.243).

**Why its own listener.** The daemon's HTTP server binds `REEMOAT_HOST`, which may
not be loopback, and `REEMOAT_PORT=0` means it has no listener at all.

**A bearer per launch.** `mcpServersFor` mints one each time an agent is handed the
server and retires the one before, so a replaced process stops naming the session;
since the 0.12.0 review it is also retired, by token, when its process ends. It
identifies the caller; it does not confine it, since every agent runs as the same
user and can read another's — the same position as `agentEnv()`.

**claude's bearer is not on a command line.** Measured 2026-10-01: claude-agent-acp
0.73.0 hands an http server's headers to the SDK, which starts the CLI with
`--mcp-config `, so the bearer sat in argv, readable by **every** local
account (`ps`, `/proc//cmdline`) — the premise above held only for the same
user. Claude Code 2.1.286 expands `${VAR}` in those headers (a probe server received
the value), and the adapter builds the CLI's environment from its own. So for claude
the bearer is minted before the spawn into `REEMOAT_MCP_BEARER`
(`AgentLaunchConfig.mcpBearerEnv`) and the header names the variable; through the
real adapter the CLI's argv carried only `${REEMOAT_MCP_BEARER}` and the server got
the value. The other five take MCP servers over stdio and get the literal header.
Rejected: a table keyed by agent id (a stub would get a header it cannot expand),
and minting in the hub before the spawn (a second callback before `initialize`).

**Rejected.**
- *A stdio shim per session* — one more process per agent, for the one transport
every measured harness already has in http (Q6.114). Kept for a harness that
needs it; none does yet.
- *MCP over ACP* (`type: "acp"`, an RFD) — it would remove the listener, but
`codex-acp` advertises `acp: false` and kimi drops such entries.
- *The MCP SDK* — it brings zod, which this repository does not use.

**Status.** Current. Between machines, see Q7.150.

### Q2.237 — Why two verbs, and why does a report arrive with the notice?

**Decision.** Codex's pair, not Claude Code's single verb. `assign_task` is work:
it starts a turn on an idle session, steers into a running one, and queues behind a
turn that cannot be steered — `submit`, the prompt route's two steps. `send_message`
is context: logged at once and never starting a turn, and put ahead of the next
turn's text, whoever starts it.
`assign_task` subscribes its sender to the recipient going idle by default; the
notice is delivered through `submit`, so a report the recipient left as context
reaches the sender **in the same turn as the notice**.

**Why.** A message that must not interrupt should cost nothing until something
else wakes the reader, and a reply to a task is exactly that. Codex splits the two
for the same reason (`send_message` does not trigger a turn; `followup_task` does).
Its `wait_agent` is not copied: in one reported run 89 waits, 88 timed out, cost
6.5% of the tokens — the push is the notice.

**Where it differs from Codex.** There, context enters the history at once and the
model sees it on its next step. ACP cannot add to a history without a prompt, and
a steer on claude pre-empts the running turn (`mid-turn-messages.md`), so context
here always waits for the next turn; what is urgent goes as `assign_task`.

**Measured** 2026-09-25, claude 2.1.281 assigning codex 0.156.1: `list_agents`,
then `assign_task`; codex woke, read the file, reported with `send_message`; the
idle notice woke claude with the report ahead of it and claude answered in that
turn — 25 s end to end, no polling.

**Status.** Reversed by Q2.243 the same day: every message is acted on, and there is
no context verb.

### Q2.238 — What stops two agents talking to each other for ever?

**Decision.** This daemon, never the model's good sense: `PEER_TURN_BUDGET` turns
caused by agents in a session with no message from its person, after which work
from agents is refused and the person is told once; `MAX_PEER_HOPS`, from
`peerDepth`, the deepest hop delivered since the person last wrote; a token bucket
per sending session; the same words to the same session inside a minute; and a
size cap. A person's message resets both counters.

**Why a budget and not only hops.** A hop count survives only while every agent
passes it on, and a cycle of two never grows deep; counting at the receiver stops
both. Notices count, or two agents assigning each other work would never stop.
Since Q2.243 every message wakes its reader, so the budget is also what stops two
agents thanking each other. Claude Code reaches the same place with a 50-message
queue per session.

**And the queue.** Peer entries hold at most `MAX_QUEUED_PEER_PROMPTS` of
`MAX_QUEUED_PROMPTS`, so other agents can never make a person's own message answer
429; consecutive ones go as one turn.

**Status.** Current. The numbers are first guesses, not measurements.

### Q2.239 — Which ended sessions may another agent reach?

**Decision.** Those that ended for a reason in `PEER_WAKE_REASONS`: parked, a config
restart, an agent that exited, the daemon going away. A person's Stop is not among
them: that session is neither listed nor woken.

**Why.** `revivableByPrompt` answers whether a *person's* message may bring a
session back, and says yes to `stopped`. An agent doing it would undo a person's
decision without asking them.

**Status.** Current.

### Q2.240 — Where does a message for a machine that is off wait?

**Decision.** On the sending daemon, in `peer_outbox`. A send whose answer is the
relay's `503` — or no answer — is held and reported `pending`, then retried by
`pumpOutbox` from 30 s to 10 min apart for 24 h, **byte-identical**, so the
receiving daemon's per-machine message-id check (Q2.241) delivers it once however
many tries it took — and since the 0.12.0 review however many restarts too: the ids
are kept in `peer_seen` for a day, because the sender gives up after 10 s while a
wake may take 45, so a retry is the common case and an in-memory set forgot it at
every restart. A delivery a shutdown cuts off answers `503 shutting_down`, which
every sender holds, rather than `ended`. A refusal on a later try, or the day
running out, wakes the sender with a notice saying so, within the budget any notice
is (Q2.243) — another machine's words only ever as a quotation in it. At most
`MAX_OUTBOX_PER_SESSION` per session and `MAX_OUTBOX` on the machine.

**Why here.** A tunnel with no daemon is a 503, never a queue (Q5.21), and the
Authority may hold none of an agent's work (`authority.md`). Claude Code holds a
message for an offline session on its own servers; the only process here that may
hold it is the one whose agent wrote it.

**Status.** Current.

### Q2.241 — What does a daemon take on a linked machine's word?

**Decision.** Which *session* on that machine sent a message, and nothing else.
Which *machine* is the capability's (`principal.link`, all three link claims or
the token is malformed). Every link has its own token bucket here, whatever the
other daemon says it enforces; a message id is delivered once per sending machine for a
day, since re-minted links hand the same sender a new link id, and kept in
`peer_seen` so a restart forgets none; a refusal is re-read too — its code kept only
if `PeerRefusal` has it, its words one line of `MAX_REMOTE_REFUSAL_CHARS`; a
notice is taken only when this machine asked for it, once (`expectedNotices`), so a
link cannot wake a session by claiming to answer it; a listing row is re-read field
by field (`remoteRowOf`), and one whose ref names a machine is dropped, while one
whose status this build does not know is kept and shown as idle (`compatibility.md`
rule 2) — dropped, it let a bare name resolve to a same-named session here. A link
reaches `/peer/*` only: `session:message` opens no other route, and a person's
capability never carries it.

**Why.** A linked machine is another computer running as the same person, which is
not the same as being right: a looping agent or a compromised host there must cost
this machine a bounded amount of work, never its owner's attention.

**Status.** Current.

### Q2.242 — Why does no claude session have its own ListAgents, and why are this daemon's tools loaded up front?

**Symptom.** Reported by the owner on 2026-09-25: a claude session driven over ACP,
asked about other agents, called Claude Code's own `ListAgents` rather than
`list_agents`. Claude Code 2.1.28x ships cross-session messaging, and the tool is in
an SDK session too. It lists Claude sessions on the machine and nothing this daemon
runs, so it answers a different question and sounds right doing it. And `list_agents`
was one step further away: claude defers an MCP tool's schema behind its tool search
(Q6.114).

**Decision.** Two changes, each where it belongs:
- `sessionMetaFor` sends `disallowedTools` naming `CLAUDE_WITHDRAWN_PEER_TOOLS` to
every claude session, whether or not it was handed the `reemoat` server.
claude-agent-acp appends it to its own list, and a disallowed tool is not in the
model's context at all. `session/new`, `session/resume` and `/clear` all carry it.
- Each of this daemon's tools carries `_meta["anthropic/alwaysLoad"]: true`, which
claude reads per tool and which keeps it out of the tool search. It costs their
schemas in every claude session's prompt. Every other harness ignores the key.

**Widened the same day.** It was first withdrawn only where the tools were handed,
so that a daemon with `REEMOAT_PEER_MESSAGES=off` took nothing of claude's away.
The owner's call: it is never wanted here, because what it lists is never what this
daemon runs, with the tools or without them.

**Measured** 2026-09-25, claude 2.1.282 under claude-agent-acp 0.73.0. Asked to name
every tool it had for other agents, it gave the three `mcp__reemoat__*` and
`SendMessage`, and no `ListAgents`. Asked which sessions it could message, it called
`mcp__reemoat__list_agents` first, with no ToolSearch before it.

**Why SendMessage stays.** It is also how claude continues a named subagent it
started, a background one included. Withdrawing it would cost claude its own
orchestration to save a tool that no longer has a listing to feed it. The server's
instructions say that a harness's own messaging tools do not reach these sessions.

**Rejected.**
- *Passing it as settings* (a deny rule, or Claude Code's crossSessionInbound). The adapter
drops the settings it builds from `CLAUDE_MODEL_CONFIG` whenever any are passed, so
a model override would vanish from every session.

**Status.** Current. Claude Code's inbound cross-session messages are not refused, for
the same settings reason.

### Q2.243 — Why does every message between agents start or join a turn?

**Symptom.** The owner, 2026-09-25, on a transcript row *Note from …· read with its
next turn* holding grok's count to a hundred: only messages the other session reacts
to. A note is logged at once and then does nothing until something else wakes its
reader, which on screen is a message that went nowhere.

**Decision.** One verb. `send_message` is what `assign_task` was: it starts a turn on
an idle session, steers into a running one, and queues behind a turn that cannot be
steered. Nothing is held for somebody else's turn, so there is no buffer and no
refusal for a full one, and an answer is a message like any other: it wakes
whoever it is for. `notify_when_idle` is off unless asked for, and the notice it
asks for **stands in for an answer**: writing back to the subscriber cancels it
(`answered`), and on the subscriber's machine the answer's arrival forgets the
notice it was expecting. A subscription that runs out lapses silently, and a message
the outbox gives up on wakes its sender with a notice.

**Why the notice is off by default.** A reply goes by the same verb as a task. On by
default, every reply would subscribe its writer to its reader going idle, and the
end of every exchange would wake the one who answered for nothing.

**What it costs.** An answer is a turn of its own for its reader, where Q2.237's
report rode the idle notice's turn; an assignment that is answered still costs its
sender one wake, not two, since the notice is not sent. A reply to a reply is a turn
too, and nothing but the tool's wording and `PEER_TURN_BUDGET` stops two agents
thanking each other.

**Rejected.**
- *Keeping `assign_task` as the one name.* An answer would have gone as a task.
- *Steering context into a running turn and buffering it only for an idle one.* The
idle session is the case that read as lost.

**Measured** 2026-09-25, claude 2.1.282 asking codex 0.157.0 on one machine, no
notice asked for: `list_agents`, then `send_message`; codex read the file and
answered with `send_message`; the answer woke claude, which summarised it and sent
nothing back. Two turns for claude, one for codex, no notice, and nothing more in the
minute after — 36 s end to end.

**Status.** Current. Reverses Q2.237.

### Q2.244 — Who may switch off messages between agents, and at which levels?

**Decision.** Three switches, each only narrowing the one above: the account's, a
machine's and a conversation's. `REEMOAT_PEER_MESSAGES=off` is still a ceiling none
of them can lift. A conversation takes part only when all four allow it. The first
two are Q1.654's, applied by `setPolicy`. The third is `peer_messages_off` on the
session row, set by `POST /sessions/:id/meta` with the same `session:write` a rename
needs, because it narrows and a grantee who can prompt the session already has more.

- **Off is checked where it is used, on the live value.** The flag stopped being
read once at boot, and every path that bypassed it is gated: the local rows of
`list_agents` behind an already-handed bearer, `/peer/notices`, the outbox pump,
and the idle notices.
- **A running agent keeps the tool names.** Its tool list was fixed at launch, so
a call is answered with a sentence rather than a missing tool. The bearer stays
valid, because a `401` from an http MCP server reads to claude as a sign-in to
start. Switching back on reaches conversations that start or resume afterwards.
- **Switching off drops what was waiting.** Queued peer prompts not yet delivered
(`dropQueuedPeer`), idle-notice subscriptions, and the outbox, with one quiet line
in each sender's transcript (`notePeerMessagesOff`) and no wake. What cannot be
taken back:
- a message already steered into a running turn;
- a turn another agent already started;
- an outbox request already on the wire.
A send inside `sendMidTurn` is dropped too since the 0.12.0 review: a steer that
fails after the switch fell through to the queue and was delivered, so
`dropQueuedPeer` bumps a counter the steer re-reads after its await.
- **A conversation that is off neither sends nor receives.** Other agents do not
see it, and it is refused both ways with `conversation_messaging_off`. A parked
one is refused without being woken first.
- **A machine may instead be isolated.** Its sessions still message each other,
but nothing reaches them from another machine and they reach none
(`reachesOthers`, `messaging_isolated`). Going isolated empties the outbox with the
same quiet line and forgets what was owed abroad; nothing local is touched. The
flag is kept while the machine is off.

**Rejected.**
- *A per-conversation switch that only stops the conversation being woken.* A
sender that is never answered.
- *Revoking bearers on off.* See the second point.

**Status.** Current. Q2.238 bounds how much agents may say to each other; this
decides whether they may.
### Q2.245 — What is a session's nickname, and what keeps it one session's?

**Decision.** Every session has a nickname — `mira`, `otto` — and it is the name
other agents address it by: `nameOf` answers it, so `list_agents` prints it,
`send_message to="mira"` resolves it and a peer message reads *Message from mira*.
- **Shape**: `NICKNAME`, lowercase latin, digits and single hyphens, starting with
a letter, 2–32 characters. It passes every daemon's `isPeerName`, the older ones
included, so a listing row is never dropped on another machine. It holds no `_`,
which `PeerHub.resolve` reads as a session id.
- **One per machine**, case-insensitive, over every session the registry holds,
ended ones included, and over the names being created right now.
`reserveNickname` takes the name synchronously at the top of `create`, before the
capacity check, the create token and `createWorkspace`, so the loser of two
concurrent creates gets `409 nickname_taken` and has made nothing.
- **Always present.** A create that names none gets `pickNickname`: a free name
from `NICKNAMES`, then one of them with the first free `-2`, `-3`. `restore()`
gives one to every row written before the column, walking rows oldest first so
the older of two duplicates keeps its name. A nickname cannot be cleared.

The title is unchanged: still derived from the first message, still renamed by a
person, still printed by `list_agents` as what the session is about. It stopped
being the address.

**Why.** A title is what a session is about, and that makes it a poor address. It
is long, it moves with every rename, and two sessions share one as soon as two
people ask for the same fix — which is why a bare name had to answer
`ambiguous_recipient` even among one machine's sessions. A handle a person chose,
or accepted, stays put.

**Rejected.**
- *A UNIQUE index.* `put` swallows its errors, and a rolled-back build writes NULL
into the column; a reservation in memory is the one check both creates pass
through.
- *One per account, across machines.* No daemon sees another's rows without the
network, and the Authority holds no sessions. The app's dice avoids every name it
can see instead (Q3.677), and an ambiguous name is answered by listing each match.

**A bare name never resolves by elimination.** Found in the 0.12.0 review: a linked
machine whose listing failed was skipped, so `mira` here and a `mira` on a machine
that did not answer resolved to this one. With any listing unchecked — no answer, a
transport failure, an unexpected status — one match is refused `ambiguous_recipient`
naming the machine and the match's full address, and none `unknown_recipient` naming
what could not be checked. A machine that answered off, isolated or too old does
not block, or one old daemon would refuse every bare name for good; a full address
waits on no listing.

**Status.** Current.

### Q2.246 — What does the agent get when a person writes `@mira`?

**Decision.** The text exactly as typed, then a second text block the daemon writes:
``, saying it is Reemoat's note and not the person's, one line per
session named — its address, title, harness, folder and machine — and
`send_message to="…"` only where this session's agent was handed the tools.
`mentionNote` builds it on the person's prompt route and nowhere else.
- **It never waits on the network.** Local rows are read in place; another
machine's are its last successful listing, `remoteSettled`, which a failed
listing clears so the note never names what `list_agents` would call unreachable.
Opening the `@` menu warms it (Q3.678).
- **At most eight names** a message, and a name two machines share lists both.
- **The switches of Q2.244 hold**: nothing is named where this machine's or this
conversation's messaging is off, and another machine's sessions only while this
one is not isolated — the listing `list_agents` would give, and no wider.
- **Not in a slash command**, since agents parse one at index 0 and a second block
beside it is unmeasured.
- **Not in a peer's envelope or a plugin's prompt**: `defuse` breaks a forged
`` tag inside a message body.
- It rides the turn the way attachments do — the steer's extra blocks, a queued
entry's `note`, `pump` — and the `prompt` event logs the names it resolved as
`mentions`, so the log says a note was added.

**Why.** An agent reading `@mira` has to guess that it names a session at all, then
list every machine to find which. The daemon already knows, and saying it once
beside the message costs nothing the agent would not spend finding out.

**Rejected.**
- *Rewriting the text.* `text` is what the web client's echo is matched on, what a
title is derived from and what `/clear` is compared with.
- *The client resolving names and sending references.* The listing is the daemon's;
a client's own rows include machines the agent cannot reach.
- *Awaiting the listings.* Up to three seconds on every message a person sends, for
a word that may be `@Override`.
- *A status in the note.* A queued message is delivered minutes after it was
accepted, and *idle* would be stale by then.

**Measured.** Not against a live agent. That a second text block reaches the model
as part of the same message is read off claude-agent-acp 0.73.0 and codex-acp 1.8.0,
each of which keeps separate text blocks separate; kimi, opencode and grok are
unmeasured.

**Status.** Current.

### Q2.247 — What does a session keep of its files, and what happens when it is full?

**Decision.** Two budgets, and both roll.
- **Files somebody sent**: 100 files and 1 GiB a session (`MAX_UPLOADS_PER_SESSION`,
`MAX_SESSION_UPLOAD_BYTES`). Past either bound the oldest file **already sent** is
dropped, row first and bytes after, to make room (`roomFor`). A file not yet sent is
never dropped, since a draft names it, so the only refusals left are a hundred files
or a gibibyte all waiting to be sent, and they say so.
- **Images an agent returned**: kept for the transcript on a budget of their own, 200
images and 256 MiB (`MAX_AGENT_IMAGES_PER_SESSION`, `MAX_SESSION_AGENT_IMAGE_BYTES`),
oldest first out, and never counted against a person's files. An id's prefix is its
kind — `u_` or `a_` — and `isAgentImage` is the one place that reads it.
- **A dropped file answers 404 `upload_not_found`**, and the transcript says
*"… is no longer kept."* where its preview was, as a download of it does.
- **An upload's type is read off its first bytes** when it declared none or only
`application/octet-stream` (`sniffImageMime`: PNG, JPEG, GIF, WebP), and the web
client sends a file's own type over the relay too (`contentTypeFor`).
- **A failed chip offers Retry only where a retry can succeed** (`uploadRetryable`): a
dropped connection, a 408, a 429 or a 5xx, never a 400, 409 or 413.

**Why.** Measured 2026-09-29 on the owner's machine: a landing-page session refused a
pasted screenshot with *"this session already holds too many staged files"*. It held
100 rows, and 96 of them were images the agent had returned while taking screenshots
of its own work — 66 JPEG and 30 PNG across three days — against the owner's 4. One
count covered both kinds and every file ever sent, and a sent row had no way out but
the session's deletion, so the agent's working screenshots locked the person out of
attaching anything, for good, in a session that looked healthy. The inode argument
behind the count (Q5.101) still holds, since each file is a directory, so the answer
is a rolling bound rather than none: a transcript's media is a display cache, and a
cache evicts rather than refuses. The person's input keeps a hard edge only where
dropping would lose something nobody has sent yet. The agent's numbers are twice what
that session produced in three days, and room for ten images at the 25 MiB one may be.

**The type, found on the way.** All four of the owner's screenshots were stored as
`application/octet-stream`. Over the relay the header came from `contentTypeFor`,
which answered bytes for any `Blob`, and `inlinesImage` hands the agent an image only
under `image/*` — so a screenshot pasted in a browser, or in the app off loopback,
reached the agent as a path rather than a picture. Reading the type off the content is
the upload advice OWASP gives; here it only fills a gap and never overrides a type the
client declared.

**Cost.** A dropped file can no longer be re-read by the path its prompt carried
(Q2.31); with a hundred newer files in the session, one that old is rarely the one a
conversation turns back to.

**Rejected.**
- *Not counting an agent's images at all.* Each is a directory on the daemon's disk,
and an agent looping on screenshots would write without bound.
- *Dropping a file not yet sent.* The draft holding its id would send a prompt naming
nothing, which `resolve` refuses as `missing`.
- *Refusing an agent's image at the bound, as before.* Every image past it was drawn
as the text `[image]`, silently.

**Status.** Current. Amends Q5.101's upload bounds, and Q2.31 on what the agent can
re-read.

### Q2.248 — Reattaching an agent that has `session/load` but no `session/resume`

**Decision.** `Session.openResumed` sends `session/resume` where the agent declares
it and `session/load` where it declares only `loadSession: true`. The load's replay
is not suppressed by any code of its own: it arrives **before** the load's answer,
and `adopt` registers the session with the client only **after** that answer, so the
router drops every replayed frame exactly as it drops any frame for an unregistered
id. `available_commands_update`, which cursor schedules after the answer, lands as
state like it does after `session/new`.

**Why.** cursor 2026.09.28 has no `session/resume` (`-32601`) and declares
`loadSession: true`. Without a second verb every cursor session is stranded by a
daemon restart and by the idle sweep (Q2.224) — its next message would answer
`ResumeUnsupportedError` for ever. Q5.85's rule existed to stop a replayed history
being written into a log that already holds it, and the ordering removes that cost
rather than the rule being ignored.

**Measured.** Read from cursor's ACP server, `loadSession` in
`./src/acp/cursor-acp-agent.ts`: it `await`s `replayConversationHistory` and only
then returns `{modes, models, configOptions}`; the replay is user text (with cursor's
appended `Additional ACP context:` block), agent text and thought, and
`tool_call`/`tool_call_update` pairs with ids `replay--`. `daemoncheck`
drives a stub that replays four frames before answering and asserts none reaches the
log, and that a command list sent after the answer does.

**Rejected.** *Mapping cursor's unknown-session answer to `SessionForgottenError`.*
It is `-32602` with a message, not `-32002`, and `-32602` is also what cursor answers
to a malformed `mcpServers` of ours — persisting `resume_gave_up` on it would strand
a session over this daemon's own bug. It costs retries instead.

**Status.** Current. Reverses Q5.85 for an agent with no `session/resume`; where
both exist resume is still the only verb sent.

### Q2.249 — A model chosen on a parked Cursor session, and the effort that did not appear

**Question.** A parked session's chips are live and a tap is recorded for the wake
(Q3.618). On 2026-09-30 the owner picked Claude Opus 5.5 on a parked Cursor session
and the effort chip stayed a dash. Why, and what should a tap do?

**Why it was a dash.** Cursor's controls other than its mode belong to the model:
`parameterizedModelPicker` makes each model bring its own — Claude Opus 5.5 an
`effort`, Codex 5.3 a `reasoning`, Auto nothing (Q6.115) — and only cursor can say
which, after `session/set_config_option` reaches it. The recorded choice reached
nobody, so the strip kept the options the parked agent last published, which were
Auto's. The log shows it: two `agent_config` rows at 17:11 carrying a new model and
no `effort`, and no `status` row between them and the park.

**Decision.** On a harness whose controls are its model's (`modelScopesControls`,
true exactly where `clientMetaFor` declares the picker, so cursor alone), a model
tapped on a **parked** session records the choice and then wakes the agent through
`resume`, whose `restoreConfig` sends it; the tap answers with what the woken agent
published. And in every deferred state the recorded model drops the old model's
controls, keeping only the mode, since `restoreConfig` would otherwise replay the old
model's `effort` onto the new one whenever the value happened to exist — overriding
the level cursor remembers for that model in `modelParameters`.

**Parked only.** A `stopped`, `agent_exited` or `agent_signed_out` session still
records and waits for a message: a person ended the first, the other two ended on a
failure a tap should not retry. A parked session is one this daemon let go for its
own reasons, and choosing a model is somebody using it.

**Cost.** A tap on a parked Cursor session spawns an agent and may evict another at
the machine's ceiling (`makeRoomForWake`), as a message would; the route already
budgets a start and a config call (`START_TIMEOUT_MS`, `SET_CONFIG_TIMEOUT_MS`), as
ultracode's restart needed. A failed wake answers `agent_config_failed` with the
choice kept, as that restart does.

**Status.** Current.

### Q2.250 — A question Cursor's model cannot ask, and the tool this daemon gives it

**Question.** Asked to put a multiple-choice question in front of its person, a
Cursor session answered in text: *"this harness has no tool for a UI with
buttons"*. Its own reasoning, in the log, looked for `AskQuestion` and found it
unavailable. `cursor/ask_question` is handled (Q6.117) — why did it never arrive?

**Measured 2026-09-30, on the owner's account, which is served Auto only** —
Composer 2.5, Codex 5.3 and Claude Opus 5.5 each answer *Upgrade your plan to
continue*. The model listed its tools, four ways: over ACP in `agent` mode, over
ACP in `plan` mode (`CreatePlan` joins), over ACP with `clientInfo` naming `zed`,
and through the terminal's own `cursor-agent -p`. Twenty-odd tools each time and
`AskQuestion` in none. The tool list is the server's, sent per request; the ACP
path tells it only `x-cursor-client-type: acp` and the host app's name, and reads
neither `--allowed-tools` nor a custom header. So nothing this client sends can ask
for it, and whether the gate is the client type, the plan or Auto is unmeasured.

**Decision. `ask_question`, served by the `reemoat` MCP server to the harnesses in
`QUESTION_TOOL_HARNESSES` — cursor alone.** Its input is cursor's own AskQuestion
shape, parsed by the same `parseQuestionRequest`, drawn by the same form builder,
so it is the card cursor's request would have drawn. Q2.14's rule stands: an agent
with a question tool of its own is never given a second.

**It returns at once, and the answer is a message.** A blocking call cannot work:
cursor calls MCP tools with no timeout option, so the SDK's default 60 s cuts any
answer given later than a minute. So `poseQuestion` opens an elicitation no request
waits on, the tool tells the model to end its turn, and settling the card sends
`answerText` through `deliverAnswer` as its answerer's message — the person's, or a
plugin's (`sessions.answerElicitation`), which neither resets nor counts the peer
budget — waking, queueing and refusing exactly as a typed one would. Submit sends the labels picked, Skip
says it was skipped, ✕ sends nothing.

**What it outlives, and what ends it.** One open at a time, refused in words
otherwise. Kept on the row in `open_question_json` and redrawn by a restarted
daemon under the same id; kept through every stop a message could revive, bar the
person's own Stop, and dismissed by Stop on the turn. This is the one pending
request that survives its agent going, which `daemon-sessions.md`'s invariant
otherwise forbids — nothing on the agent's side is waiting on it. While open the
session reads `blocked`, so it is not parked.

**The permission in front of it is answered by the daemon**, the owner's call:
cursor asks before every MCP call not in its allowlist, and the card behind this
one is the consent that permission would ask for. `Session` learns the call is
this tool from the `rawInput` cursor puts on its `tool_call_update` first
(`readMcpToolCall`), answers `allow-once`, and logs it as a decision, the path a
session with no resolver takes. Nothing is written to `~/.cursor/cli-config.json`.

**No messaging switch withdraws it.** A question to your own person is not a
message to another agent, so the endpoint now always listens, the server is
injected for a question-tool harness with messaging off, holding that tool alone,
and `callTool` answers it before the messaging refusal. Questions off
(`REEMOAT_ELICITATION=0`) withdraw it.

**Measured live the same day**, this tool's own definition on a loopback server:
asked for a choice, the model called `reemoat: ask_question` by itself with a title,
one question and three options, then ended its turn with *"pick an option on the
card above"*. The `rawInput` naming the tool arrived 6 ms before the permission, and
`tools/call` 3 ms after it was answered.

**Status.** Current, and **amended by Q2.251**: the call now waits for the answer,
and the message is only what an answer later than that becomes. If cursor starts
sending `cursor/ask_question`, the model has two ways to ask and both draw the same
card.

### Q2.251 — A Cursor question answered as every other harness's is

**Question.** The owner, on a cursor session, 2026-10-01: the answer appeared as their
own message — a bubble reading *"Answer to your ask_question: … — …"* — under the
answered card, *"if this is how asking is done, it must be done as for the other
agents, with no difference at all"*. Read off that session's log, the difference was
four rows, not one: the `reemoat: ask_question` tool row, a `permission_request` the
daemon had answered itself (drawn *asked: … (answered)*), the model's *"the card is
on screen — pick an option"* and its turn ending, then the bubble and a new turn.

**Why it returned at once.** Q2.250's measurement stands and was read again, this time
off cursor 2026.09.28's own bundle: `McpSdkClient.callTool` calls the SDK's
`client.callTool({name, arguments})` with no options, so the request gets the SDK's
`timeout ?? 6e4` and `resetTimeoutOnProgress ?? false` — 60 s, and no progress
notification moves it. So a call cannot wait for a person who takes longer.

**Decision. It waits as long as it may.** `poseQuestion` holds the call open for
`ASK_WAIT_MS` (50 s, ten under cursor's cut, the permission in front having already
been answered); an answer in that time settles `posedWaiter` and is the call's own
result (`answerResult`), so the turn goes on and nothing is sent — what claude's
question does. Past it, or when the client drops the POST (`res` closing aborts the
wait), the call returns `ASK_PENDING`, which tells the model to end its turn writing
nothing, and the answer goes as Q2.250's message. Skip and ✕ are results too, since
a call has to return something.

**And the transcript draws it as claude's.** The card takes the call's id —
`Session.claimPosedCall`, the newest call whose `rawInput` named the tool, cleared
when that call ends — and keeps it on `open_question_json` across a restart, so
`askedThrough` folds the call away and `askedInput` reads the questions off cursor's
MCP wrapper. A `permission_request` the daemon answered (`permissionId: null`) on a
call that asked is not drawn. A late answer's prompt carries `answers` (the
elicitation id) and is not drawn either: the card above already shows it.

**What is still different, past 50 s.** The model ends its turn and a new one starts
with the answer; it is told to write nothing, which it may not honour. Held longer
would need a client that passes a timeout, or a loop of calls each under 60 s, which
spends a model request a minute on nobody answering — not built.

**Status.** Current.

### Q2.252 — A file the agent hands over on purpose

**Question.** Q3.690 ended *"A way for an agent to hand a file over on purpose would
be a tool of its own"*. Until now a file reached its person only where a tool call
had read or written it inside the workspace; a PDF made by a shell command, or
anything in `/tmp`, was a path printed at somebody who may be on a phone.

**Decision. `send_file`, on the `reemoat` MCP server, for every agent that takes the
server.** One argument, `path`: absolute, from `~`, or relative to the session's
working folder. The daemon **copies the file as it stands** into the session's upload
store and appends one event, `file_sent`, carrying a `StoredFileRef` and nothing
else; the app draws a card, an image previewed through `previewable` like every
other, and a press saves it through `GET /sessions/:id/uploads/:uploadId`. No bytes
cross the MCP call, whose body is 256 KiB, and no route was added.

**A copy, never a path.** The log outlives the disk, which is `StoredFileRef`'s own
reason; `/files` serves only under `workspace.root`, and what somebody asks for is
as often outside it; and the card has to open after the agent overwrites the
original. So a file is sent again after it changes, and the tool says so.

**Nothing is contained, and that is the honest reading of what is.** The agent runs
as the user and can read the file already, so the path is refused only for what it
is: missing, not a regular file, over `MAX_SENT_FILE_BYTES`, or on a filesystem that
does not answer. Each is a sentence to the model (`sendFileRefusal`), never a 4xx.

**The copy, in the order that has to hold** (`Uploads.keepAgentFile`): the rate
window, `probeRealpath`, `probeFile`, an open with `O_NONBLOCK` so a pipe swapped in
after the probe cannot park it, `fstat` on the handle, the copy under a running
byte counter and the call's own abort signal, then the row — the commit point,
inserted already consumed — and only then the eviction. A refusal before the copy
leaves nothing; one inside it removes the directory; a crash before the row is
`reconcile`'s. Calls from one session run one after another, so each is charged and
bounded in the order it came. **45 s for the whole call**, its wait behind another
included, which is under the 60 s an MCP client gives one (Q2.251): a copy that
outlived its call would put a file in the chat the model saw fail, and the model
would send it again. `sendFile` asks whether the session is still running a second
time, after the copy, for a Stop that landed inside it. ⚠ A read that stalls after
the probes is given up on and still holds its thread, as the download route's does.

**A third budget.** Sent files are `f_` rows: 100 of them or 1 GiB, oldest first
out, with a rate window of their own. `sentFiles` counts a person's files alone, so
an agent's loop can neither fill a person's budget, nor be evicted by their upload,
nor answer it with 429 — the argument `keepAgentImage`'s budget already made.

**The name is the agent's, which no upload's ever was.** `sentFileName` drops
controls, bidi and zero-width characters rather than refusing: a right-to-left
override in front of `fdp.exe` reads as a PDF in a save panel.

**No messaging switch withdraws it**, for Q2.250's reason: a file goes to the
session's own person. So `mcpServersFor` now hands the server to every http-capable
agent wherever there is an upload store, with messaging off too, and `callTool`
answers it before `callRefusal`. `REEMOAT_PEER_MESSAGES=off` removes the messaging
tools, no longer the server.

**The permission in front of it is answered by the daemon, the owner's call
2026-10-02** — the agent is meant to send a file when it judges one wanted, and a
card for each would undo that. How, per harness, measured the same day on a daemon
running this tree:

| Harness | The call as announced | The permission |
|---|---|---|
| claude 2.1.287 | `tool_call` with `_meta.claudeCode.toolName` `mcp__reemoat__send_file` | none: `allowedTools` in `sessionMetaFor`, which the SDK applies before `canUseTool` |
| codex 0.160.0 | `rawInput` `{server, tool, arguments}` | none reached the client: its Guardian approved, *"Risk: low"* |
| grok 1.0.40 | `use_tool`, `rawInput` `{tool_name: "reemoat__send_file", tool_input}`, then the request on the same id | answered `allow-once` here |
| cursor | `rawInput` `{providerIdentifier, toolName, args}` (Q6.114) | answered `allow-once` here; not run live, its keychain being locked in the shell that measured |
| opencode 1.18.34 | titled `reemoat_send_file`, `rawInput` `{path}` | none arrived |

`ownToolCall` reads each shape **for its own harness only**: on another, the same
keys are whatever a model typed. grok's is the one a model does type — they are
`use_tool`'s arguments — so there the call is answered only once grok itself has
vouched for it: the `variant: "UseTool"` it adds to those arguments after parsing
them, which the request carries and the first announcement does not. A call
carrying any other key is not one, and a call that later says it is something else
is forgotten. The answer is only ever `allow_once`: the fallback to `allow_always`
that `ask_question` may take would write a rule into the person's own harness
config. An unrecognised call falls to the person's card, and so does a subagent's.

**The card stands for the call.** `file_sent.toolCallId` is the harness's own call
where `claimSentFileCall` could tell — by the path it named, else the oldest
unclaimed — and the app then draws neither that call's row nor the daemon's answer
to its permission, as it does for a question. opencode names the tool only in a
title, which nothing here reads, so there the row and the card are both drawn.

**Compatibility.** An app that predates the event draws nothing for it and still
shows the harness's own tool row, while the model is told the file was sent: so the
app ships first, then the daemons. A daemon older than this cannot weigh a stored
`file_sent`, so it is not rolled back under a log that holds one.

**Not built.** A switch that withholds the tool; several files in one call; a
folder; a bridge that would give an older app a button.

**Status.** Current. Amended by Q2.253.

### Q2.253 — send_file, checked again: what a Stop, a stall, a closed folder and a typed tag could do

**Question.** Q2.252 was built in a day and the owner asked for it to be read again
properly. Two independent reviews on 2026-10-03, one of the copy and one of the
recognition and the permission, each reproduced what it claimed with a script.

**A Stop during the copy kept a file nobody could see and dropped one somebody
could.** `keepAgentFile` inserted the row and evicted the oldest before it returned,
and `sendFile` asked whether the session was still running only afterwards — so at
the 100-file budget a Stop landing mid-copy answered *not running*, kept the row and
its bytes with no `file_sent`, and had already thrown away a file the transcript
still drew. **Decision:** `KeepFileOptions.kept`, called in the insert's own
synchronous block — after the insert, so what it records names a row that exists,
and before the eviction, so a no evicts nothing. `sendFile` answers there: a session
that went keeps nothing (`withdrawn`), and the event lands with its row or not at
all. A crash can no longer fall between the two.

**A copy that stalled was forgotten, so the next one stalled too.** The probes feed
`stall.ts`'s memory; the open and the reads, raced against the deadline, did not —
and a mount that answers metadata from a cache and stalls on data passes the probes
every time, so each retry pinned another threadpool slot. **Decision:** a source call
still out at the deadline, and out since before `DESCRIBE_TIMEOUT_MS`, is remembered
(`noteStalled`) and answered `unresponsive`; one that was merely slow stays
`timed_out`, which is a different sentence.

**Every realpath error said there was no file.** A file under a mode-000 folder came
back *there is no file at …*. **Decision:** `PathResolution` carries the errno;
ENOENT and ENOTDIR are missing, EACCES and EPERM are `denied`, a link loop and an
over-long path say so.

**Waiting in line ignored the call's own abort and deadline.** A call behind a long
copy answered its abort only once that copy finished. **Decision:** the wait is
raced against both (`settledOrStopped`), and the next call still queues behind
**both** the copy ahead and the one that gave up, or two copies would run at once.
The probes and the mount table are raced too.

**Smaller, each reproduced or read off the code.** A long name cut through a
surrogate pair, which SQLite stores as U+FFFD while the event held the half: names
are cut by code point, and a lone surrogate the agent sent is dropped. A relative
path read from the wrong folder sent the wrong file silently: every answer names
the path that was read — in the structured result too, since claude shows its model
that half alone (measured on 2.1.288) — and the tool says which folder a relative
path is taken from. Only ASCII whitespace is trimmed, a no-break space being part of
a real name. A short write is finished. All of `/proc` is refused on Linux: a
process's `environ` holds the machine's token, and the daemon's own pid was not the
only way to it — every thread is `/proc/` by name though never listed, and the
`tsx` parent carries the same environment (review, 2026-10-04). Decided twice, on the
resolved path and on the opened descriptor's device, since a folder on the way can be
swapped for a link after the probe. Old rate charges are swept.

**What a permission answer trusted.** grok's `variant: "UseTool"` was believed
wherever it appeared, including the first announcement — whose `rawInput` is the
model's own typing — and once believed it stayed: a model typing the tag made a bare
request on that id an `allow-once`. **Decision:** on grok only the request's own
`toolCall` vouches (`noteOwnCall`'s `fromRequest`). A call that completed or failed
is ended, and nothing later said about its id is believed; another tool of this
server on the same id is forgotten; `/clear` empties both maps.

**claude's request is its person's.** `allowedTools` lets the SDK run send_file
before `canUseTool`; the adapter's own comment says a request that still reaches
the client is *bypass-immune* — a safety check, or an explicit ask rule somebody
wrote. So the daemon no longer answers claude's, and a subagent's asks its person
on every harness, which Q2.252 said and only cursor did.

**Which call a file stands for.** `claimSentFileCall` took the *newest* call naming
the path, so two in flight on one path swapped ids and the first card hid the
second call's row, failure included. It takes the oldest now, and a call announced
and never claimed is dropped at its turn's end and at a `/clear`, which is what the
newest-first rule had been standing in for. `ask_question`'s auto-answer now
requires `allow_once` as send_file's does: falling back to `allow_always` wrote
`Mcp(reemoat:ask_question)` into cursor's own config.

**Checked and sound**, so nobody re-derives it: the download route's headers and
type, the three budgets kept apart, descriptors closed on every path, a FIFO or a
device refused twice, `reconcile` after a crash, look-alike server names, codex's
shape being unforgeable by a model, and none of the 29 withdrawn claude names being
an alias (the three MCP-resource aliases joined the driver's guard).

**Not done.** A per-session lock around `forgetSession`, which runs only for
sessions pruned at startup; codex's MCP approvals arriving as elicitations, which
nothing answers for it.

**Status.** Current. Amends Q2.252.

### Q2.254 — What the controls show while a released agent comes back

**Reported 2026-10-03 by the owner**: on a wake the strip under the message box
twitched, *"as if for a moment the effort switched to the default"*.

**Measured on that session's own log.** A wake opens a fresh agent on its own
defaults and `restoreConfig` then walks the session's choices back, one call each.
Every step was written and fanned out. 18963 `mode=default, effort=default` at
16:26:06.074, then `mode=auto` twice at .084, then `effort=xhigh` at .107: four
snapshots in 33 ms, and the person saw the first three, which are not their session.
`restartAgent` had always held its captured config over that window
(`snapshotConfigSource`); a wake held nothing.

**Decision.** `doResume` holds the config it captured, `wakeConfig`, from before the
spawn until the restore settles. The snapshot serves it over the agent's defaults,
and `applyAgentConfig` writes no event while it is held. When the restore settles,
one `agent_config` is written for where it landed. That is the held set unless the
agent refused or withdrew part of it, so a value that did not come back still shows
as it really is. A tap in the window was already refused as busy (`resuming`), so
nothing needed holding against a person.

Covers every wake: a message to a parked session, a daemon restart's pass and
Resume. `daemoncheck` samples the snapshot at the moment the fresh agent, still on
its default, receives the replay; without the hold it read the default, and the log
held three events where it now holds one.

**Status.** Current.

### Q2.255 — A cancel the agent never honours

**Reported 2026-10-03 by the owner** on session lyra, measured on its log and processes.
claude CLI 2.1.288 stopped mid-response at 22:16:19: a Bash `tool_call` complete, a
`ToolSearch` begun, neither run. The CLI and adapter were alive at 0% CPU with no
children, every socket to the API `CLOSED`, and its own transcript ended before that
response. Stop sent `session/cancel`; the adapter's floor (`forceCancelGraceMs`, 30 s)
resolved the prompt `cancelled` and logged *"the underlying query may still be wedged"*.
A message sent during those 30 s was queued, and when the turn ended the daemon handed it
to the same CLI, which wedged that turn too. Even SIGTERM left both processes standing;
SIGKILL ended them. Only the 3 h silence bound (Q2.231) would have ended either turn.

**Decision.** The first cancel of a turn arms `WEDGED_CANCEL_MS` (15 s, under claude's
floor). If the turn is still open then, the daemon ends it in the log as `cancelled`
(`Session.abandonTurn("cancelled")`, through the pump, so it is written once) and
replaces the process with `restartAgent`: a stop as `config_changed`, which keeps the
queue and kills past the dispose grace, then a resume of the same conversation. The
queue is handed to the new agent, never the old one. A turn ending sooner disarms it; a
repeated Stop does not push it out.

**Why the daemon and not the adapter.** We patch claude's adapter (Q6.121), but a wedge
is not claude's alone. The daemon's own clock covers every harness, and replacing a
process is what `onAgentUnusable` already does for a rejected prompt (Q7.99). An agent
that takes longer than 15 s to honour a cancel is replaced unnecessarily, at the cost of
a resume; claude's interrupt takes well under the 1.5 s `CANCEL_SETTLE_MS`.

**Two holds, from the review (2026-10-04).** A session reporting live background work is
not replaced: the restart kills the process group, and with it a dev server the agent
left running, so the turn stays open as before and End session is the escalation (the
owner's call). And a person's stop that lands while the replacement is stopping the old
agent joined that stop, whose resume then brought the agent back with the queue: `stop`
records the reason (`stopDuringRestart`), and `restartAgent` records it as the exit and
resumes nothing. Both are older than this entry for ultracode and credential restarts;
this made them reachable seconds after a Stop.

**Not changed.** A silent turn (Q2.231) still only abandons, so the next message after it
may meet the same agent; a Stop then replaces it. `daemoncheck` drives a stub that never
answers a cancel, with a message sent while the cancel is pending: one `turn_end`, a
second launch that resumes, and the message delivered to it.

**Status.** Current.

## The web client

### What the client is

#### Q3.1 — What is the web client, and did it replace the terminal client?

**Decision.** `packages/web` is a plain React + Vite + Tailwind SPA, built to
static files by `pnpm web:build` and served by the control plane at `/`. There is
no Electron, no service worker and no push. `scripts/client.ts` remains, still as
the regression driver for the terminal, but it is no longer the only way in.

**Why.** The web UI is how the system is actually used; the terminal client's
remaining job is to be a reference implementation of the token and replay logic
that the browser mirrors.

**Status.** Current — and **narrowed by Q3.605**, which is where to read before
concluding anything from the "no Electron" clause. There is a native shell now
(`packages/native`, a Tauri window); what that clause was actually refusing — a
second copy of the product with its own runtime and its own drift — is still
refused, and there is exactly one bundle. The service worker and the push are
untouched.

#### Q3.2 — How does the screen answer "does anything anywhere need me"?

**Decision.** The answer travels *with the rows* rather than living in a mode
that has to be entered. A session waiting on a human says so on the status dot
every row already carries — amber, haloed, the loudest static thing in the list —
and shows what it is waiting for instead of its path. Its machine's header
carries the count, *in place of* the live count rather than beside it.

**Why.** Because the signal is on the row, the answer is true under every filter,
and approving is two taps from open with the command or diff on screen — never a
wall of transcript to scroll past first.

**Status.** Current

### Nothing in a row mounts sideways

#### Q3.3 — Why is there no warning triangle in front of the status dot?

**Decision.** The triangle is deleted. The dot and the subline already say a
session is waiting; a third glyph said it again.

**Why.** It was the only one of the three that *moved* anything: mounting it
pushed the dot, the name and the subline 21px right, at exactly the moment the
row mattered most. The general rule the screen now follows is that **nothing in a
row mounts sideways into another control.** Two shapes of the problem kept
recurring — a glyph that appears when a session becomes interesting (the
triangle; the pin beside a session's name), and a readout whose *own* width
changes (the context percentage at `9% → 10%`).

**Status.** Current

#### Q3.4 — When something in a row can change width, which of the three remedies applies?

**Decision.** *Delete it* when the thing is redundant — the triangle said what the
dot and the subline already said, so it is gone rather than reserved. *Reserve its
slot* when it is the only copy — the pin, the home spinner and the `Toggle`
spinner each get a fixed box sized by exactly what it holds, drawn empty
otherwise. *Move it off the row* when it is neither redundant nor fixed-width —
the context percentage went into a popover.

**Why.** The choice between the three remedies is the interesting part; a single
blanket remedy would reserve space for redundant things and leave genuinely
variable ones unfixed.

**Rejected.** A widest-label constant. Because the ring left behind by moving the
percentage off the row is one width at every value, there is deliberately **no**
such constant anywhere — looking for one is looking for something that was
considered and rejected.

**Status.** Current

#### Q3.5 — Which mounting glyphs actually displace anything?

**Decision.** Measured rather than assumed: a mount only displaces what lies
between it and the nearest `flex-1` sibling.

**Measured.** The spinner in the home header displaces nothing; the pin beside a
session's name displaces the name.

**Why.** Reserving a slot costs layout and code, so it is spent only where a mount
really moves a neighbour.

**Status.** Current

#### Q3.6 — Why do centred things in the transcript slide left when a card is expanded?

**Decision.** The cause is the scrollbar, not anything in a row. `index.css` sets
`scrollbar-width: thin` under `@media (pointer: fine)`, which is a bar that takes
layout width rather than one that floats over the content the way a phone's does.

**Why.** A box crossing from fitting to not fitting loses about eight pixels of
`clientWidth`, and everything *centred* inside it re-centres by half of that. In
the transcript the trigger is expanding a tool call or a subagent card: it adds
height, height crosses the threshold, and the control at the top, the turn-end
line, a gap marker, the context-cleared divider and the right-hand edge of every
message bubble all slide left together while nothing left-aligned moves at all.
That asymmetry is what made it hard to place — it reads as *some* things shifting.

**Status.** Current

#### Q3.7 — How is the scrollbar shift fixed, and why not globally?

**Decision.** Reserve the gutter: `scrollbar-gutter: stable`, applied as
`.scroll-stable` on the three boxes whose width other things are measured against
— the transcript, and `AppShell`'s two panes. The one row that was centred for no
reason, the control at the top of the transcript (a `w-full` `

` promotion is free: `syncInert` puts `inert` on `#root` for the life of any sheet and `inert` implies `aria-hidden`, so `SessionBrowser`'s own `