Phase C server half, and a real flaw in phase B.
On the subprocess path a second message could only supersede — kill the process, start again,
lose the turn — because opencode run has no input channel. The serve takes another prompt
into the running turn, so a message arriving mid-turn is handed over with delivery steer and
the existing turn is left exactly as it is.
Keeping the same turn object is the load-bearing part. Phase B retired it and registered a
replacement, which stops officer routing events the serve is still producing while the serve
carries on regardless: output goes nowhere and the turn looks hung.
Verified end to end through the chat socket — sent a count to 50, injected a change of plan
eight seconds in, and BANANA INJECTED came back inside the same turn with deltas streaming
throughout.
No client change was needed. Officer composer already sends while generating; the difference
is only what the sidecar does with it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Real icons are coming and the manifest field already exists — slskd uses it. What is not decided is
where the bytes come from for a sidecar that ships from its own repository: /slskd.png works only
because it sits in the platform's public/, which a marketplace plugin cannot write to.
Records the three options and their trade — marketplace URL (loses icons offline), served by us from the
sidecar's directory (works offline, needs a route and caching), or a data URI (no fetch, but bloats
every manifest) — so the next person meets the question instead of assuming the current path generalises.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two gaps, both from the same root: the app knew what an account MAY use and not what this server
actually HAS.
Availability is now subtracted server-side in the /capabilities answer. "Installed" is orthogonal to
"permitted" and the owner is subject to it — the owner bypasses every permission check, but a capability
they hold unconditionally still means nothing if its sidecar was never installed. Without this the dock
on a fresh machine lists Photos, Jellyfin, Transmission and the rest, each leading to a screen that
reports itself unavailable.
Computed on the server rather than intersected in the client, so the rule lives in one place: the dock
already reads `/capabilities`, and making it read a second list and combine them is how a member's dock
and an owner's dock drift apart. `unavailable` is returned alongside `deniedRoutes` because the two mean
different things to a UI — "not yours" versus "not here yet, install it".
A disabled sidecar counts as unavailable: disable stops the process and its container, so the feature
genuinely does not work, and leaving its icon would make disable look broken rather than effective.
Reading install state failing subtracts NOTHING, matching useCapabilities' deliberate fail-open.
Each entry now also carries a UI manifest — name, icon, colour, rootRoute, routes — because a sidecar
shipping from its own repository has to be able to say what it looks like. The icon is a NAME rather
than an imported component: a manifest has to survive being JSON from marketplace.officer.dev, which a
lucide import cannot make. Tests pin the manifests against the capability registry, so a tile cannot
appear for a route the server guards differently, and against each other, so two sidecars cannot claim
one root route.
No backfill, by decision: this is proven on a blank machine first and applied to alpha from scratch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
OPENCODE_TURNS=serve picks the new engine; unset keeps the subprocess, which is the default
and stays the default until this has been lived with. A bad evening should cost one restart,
not a revert. Claude is a different sidecar and is untouched.
Verified end to end through the real chat socket:
session:init -> tool:start(bash) -> tool:result -> assistant:delta x3 -> assistant:text
-> result, cost in=304 out=73
Those deltas are the first token streaming an opencode turn has ever produced in officer.
Stop is now an INTERRUPT: the turn ends and the session survives — verified by sending a
second prompt to the same session afterwards and getting an answer, which killing a
subprocess could never do.
Reads the LIVE global stream rather than the durable per-session one, because it is a strict
superset — same tool.called, tool.success, step.ended, text.ended, plus the deltas that are
the whole point. Global means one socket carries every session, so everything filters on
sessionID; one subscription is shared for the process rather than one per turn.
A turn ends on step.ended with finish != tool-calls. tool-calls is a step boundary MID-turn,
and treating it as terminal would cut every tool-using conversation in half.
delivery is stated explicitly as queue because it DEFAULTS to steer, which injects into a
running turn — wrong for an ordinary send, where two quick messages would merge into one.
Wiring steer to the button that means it is phase C.
What phase B does not do: read the durable stream. The sidecar still commits every event to
chat_session_events as it arrives, so durability is unchanged, but recovering a turn this
process never saw needs the ?after= cursor and is its own change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The mapping half of the serve migration, written and pinned before anything depends on it,
so the switch-over is not also the moment the parsing turns out to be wrong. Nothing routes
through this — turns are still opencode run subprocesses, and the claude path is untouched.
The finding that matters: the serve publishes each turn TWICE, and reading the wrong one
makes it look like it cannot stream at all.
/api/session/{id}/event?after= durable, per session, replayable, durable.seq on every
event, whole values only, NO deltas
/api/event live, GLOBAL, ephemeral, carries text.delta and
tool.input.delta, no cursor
Same turn: 13 events durable, 21 live, the difference being 3 text.delta and 5
tool.input.delta. I probed the per-session one first and nearly recorded "no streaming" as
a fact — it would have removed the main reason to migrate. The split maps exactly onto what
officer already does for claude: durable to chat_session_events, live to UI deltas. The cost
is that the live stream is global, so a consumer must filter on sessionID.
tool:start is emitted on tool.called, not tool.input.started, because only tool.called has
the resolved input object — the input arrives as JSON fragments ({"comman) and a tool row
rendered with half-parsed arguments is worse than one that appears a moment later.
step.ended with finish tool-calls is a step boundary MID-turn, not the end of the turn, so
nothing terminal is emitted for it. Treating it as the end would cut every tool-using
conversation in half.
Fixtures are verbatim captures from 1.18.16. Replaying both real streams through the mapper
reconstructs the turn identically from each, with the reassembled deltas exactly equal to
the committed text and identical cost, and zero unrecognised events.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Crash-recovery state is not a gap: state:sync goes to the proxy capability and carries
proxySecret, and syncState/getCachedState have no callers at all. The row compared opencode
against a mechanism officer never consults. The real recovery story now exists and is better
— a sidecar restart stops in-flight turns and writes the reason to chat_session_events.
Identity is deferred, not forgotten: TODO.md already records it, and chat is kind execution,
which the grants API refuses to share at any level, so no member can reach it.
Also adds the serve migration plan, written while the facts are fresh and nothing is on
fire. It leads with the five things that will bite whoever implements it — per-request
location, the data wrapper, delivery defaulting to steer, silent failure on an unconnected
credential, and the session.next event names — because none of them are in the API docs and
each cost time to find today.
Phased so the old path stays one config flip away, and so warm-session lifetime (idle GC,
orphan adoption, the supersede race) is imported deliberately rather than discovered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bun.spawn throws on a missing or non-executable binary rather than resolving to a failed
process, and that throw escaped runOpenCodeTurn entirely — past the bookkeeping, out of the
sidecar command handler, with no opencode:event ever emitted. The browser sat on a spinner
nothing could end, because the code that ends turns had not been reached.
A wrong OPENCODE_BIN is the ordinary way to get there, so the message names the path it
tried: that is the difference between a fix and a debugging session.
Also records that messageCount is not a gap. SessionList renders an OpenCode badge in place
of the count for those rows, so the hardcoded 0 never reaches a screen, and computing a real
one would cost an HTTP call per listed session — the session record has no count field — to
populate something nothing shows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
opencode keeps credentials in two unrelated places. The CLI, opencode run and the legacy
/session surface read auth.json. The newer /api surface — the one with steer, queue,
interrupt and a resumable per-session stream — reads its own integration store and knows
nothing about that file.
With none connected it does not fail. It falls back to what needs no credential, the free
tier, and a request for a paid model is never executed: prompt accepted, admitted, prompted,
then no step, no error, no message, forever. That silence cost most of an afternoon and would
cost it again on every new machine — alpha included.
So the sidecar does it, rather than depending on someone having run a curl. Best-effort and
never blocking: turns go through opencode run, which reads auth.json and does not care.
Retried, because /api/health answers before the integration store is ready — the first
version of this shipped without a retry and failed on its very first real boot with a 500,
while the identical request succeeded seconds later. Only 5xx retries; a 4xx means the
request is wrong and repeating it just prints the same complaint six times.
Verified by deleting the credential, restarting, and running sonnet on the new pipeline with
no manual step.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Andre said his terminal opencode reaches paid zen models and suggested it was simply not set
up here. Correct, and my second wrong call on this page.
The new /api pipeline has its own credential store — /api/integration and /api/credential —
separate from auth.json, which is what the CLI, opencode run and the legacy /session surface
read. Ours had none connected, so it fell back to what needs no credential: the free tier.
One POST to /api/integration/opencode/connect/key fixes it, and it survives a serve restart.
sonnet and haiku both run on the new pipeline now.
The tell I had and did not use: the configured default is big-pickle, and a session with no
model ran on ling-3.0-tiny-free INSTEAD of the default. A pipeline ignoring its configured
default cannot use it — a credential symptom, sitting in /config/providers the whole time.
So steer, queue, interrupt and the resumable per-session SSE are all available with real
models. alpha needs the same one-time connect, and the sidecar should do it at boot rather
than depend on someone having run it by hand.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Follow-up to the /vaultwarden mount: the suffix is superfluous if officer can tell a
bitwarden client apart, and it can.
Most of vaultwarden surface does not collide at all — /identity, /notifications, /icons and
/events belong to it and to nothing here, so those are served at the root by path alone, no
sniffing. Only /api collides (vaultwarden has /api/settings/domains, officer has
/api/settings), and there the client says who it is: every bitwarden client stamps
Bitwarden-Client-Name, older ones Device-Type.
Trusting a client header is fine because this is ROUTING, not authentication — the worst a
forged one achieves is reaching vaultwarden, which then demands its own credential exactly
as it would have. Nothing is authorised by it.
Registered before /api so it wins for a bitwarden client, and narrow enough that an ordinary
officer request never matches. Verified: /identity reaches the proxy, /api/sync with the
header diverts, /api/chat/models without it still answers 401 from officer, and the SPA is
untouched. /vaultwarden still works for anything that prefers an explicit path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
So the bitwarden browser extension can point here and the separate public vaultwarden
hostname can be taken down.
/api/vault cannot serve it: that router requires an officer session and REPLACES the caller
Authorization header with a server-held vaultwarden token. Right for our own clients — the
device then holds no vault credential — and impossible for a third-party client that gets
its own token from /identity/connect/token and has nowhere to put a platform JWT.
So a separate mount rather than a mode of that router: blending them would put an
unauthenticated branch inside the authenticated path. This one forwards Authorization
untouched and rewrites nothing.
Leaving it open is not a new exposure — everything here was already reachable at the
vaultwarden URL it replaces, behind the same master password, and officer cannot add a check
it has no credential for. It is also going behind tailscale.
Temporary. The end state is our own extension reusing @officer/vault, which already runs as
a plain JS bundle outside react native (the iOS autofill extension hosts it in
JavaScriptCore), against the /api/vault/session/login broker — then nothing addresses
vaultwarden directly and this mount is deleted rather than adjusted.
Needed its own entry in server.tsx: only listed paths reach hono and the rest fall through
to the SPA, so without it the endpoint answered 200 with the react shell — a missing route
that looks like a working one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Regression from my own B7 change, reported within the hour: turns collapsing to "turn
completed without output" and coming back only on refresh.
B7 stopped resume-cursor defaulting an unidentified session to claude-code. Correct for the
durable cut-off row, wrong for adoption: useChat sends model only if modelRef.current is
set, so a reconnect without one is routine, not exotic. Declining to adopt left the socket
unbound to the live session, so the running turn output went nowhere — and a refresh looked
like a fix because it rebuilds from the durable log.
Adoption is about DELIVERY and must be generous; only the durable write needs certainty. So
adopt on the default again, mark it as an assumption, and skip the cut-off check on it.
That keeps B7 fixed — no false "agent went away" written against an opencode session — with
no unbound sockets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Same shape as the claude side, which has never shown a live row without a name.
OpenCode titles a session from the conversation and does it well, but asynchronously — so
for the whole time a turn is RUNNING, which is exactly what /chat/live shows, the session is
still called "New session - <ISO>". Its own title wins the moment it exists; until then the
row falls back to the prompt that started the session.
Kept per sessionKey, first turn only, so it stays the name of the conversation rather than
following whatever was asked most recently. Dropped with the session id it sits beside.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
OpenCode titles a session from the conversation, but asynchronously — a finished turn of
ours ended up called "Single color in oc-red2.png", better than anything we would generate.
Until then the session is literally named "New session - 2026-08-10T15:44:17.178Z".
That window is exactly when a session is most visible: /chat/live shows turns that are
RUNNING, so the placeholder is what the panel catches, and a live row was being labelled
with a timestamp string.
Recognise it and treat it as untitled, so the good name arrives on its own. Passing --title
on the run was the other option and is worse: it fixes the transient case by permanently
replacing opencode own title with a truncated prompt, degrading it where it lasts longest.
A pattern match rather than startsWith, because a genuine title is allowed to begin with
those words. Two defects the tests caught while writing them: a whitespace-only title was
not treated as unnamed, and the mapping let undefined through where a string was required.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bucket 1 lists them as No, and phase 4 put them behind the migration. opencode run takes
--file, so the path we already use carries them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B4 properly. The composer gate was the honest stopgap; this is the fix. opencode run takes
attachments with --file, so images work on the subprocess path we already use — the parity
doc had them down as phase 4, behind the serve migration, and they were not.
The bug was one omission: handleOpenCodeChat`s msg type had no images field, so the browser
sent them, the bubble rendered them, and they stopped at that signature. Nothing reported a
loss anywhere.
Attachments are paths, not inline data, so the sidecar spills each image to a temp file for
the length of the turn and removes it in settle — the same place every other per-turn
resource is released, so a killed or superseded turn cleans up too.
The load-bearing detail is `--` before the prompt: --file is an array option, so without the
separator the prompt is eaten as another filename and the turn dies with "File not found:"
followed by the entire message. Confirmed against the binary, and pinned by a test that
records argv from a stub.
list-models now reports each model own capability instead of a hardcoded false — opencode
publishes capabilities.input.image per model and nothing had ever read it. Defaults to false,
so a model that does not declare it keeps the affordance hidden.
Verified end to end: a red png sent over the chat socket to opencode/claude-sonnet-4-6 came
back "Red".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Email installs end to end now, which was the point of picking it as tier one: no container, no external
wiring, so the machinery is exercised without the provisioning half.
Verified against the running system, not asserted:
POST /api/app-store/email/install -> {"status":"installed","completed":["preflight","schema","process"]}
row -> email mode=config status=installed enabled=true
pm2 -> officer-email online
second install -> all three steps skipped, process not restarted
disable -> stopped
The server boots with the new router, which is the real test of the capability entry: totality.ts throws
before serve() if a mounted router has none, so booting IS the check passing.
pm2.ts shells out rather than importing pm2 as a library. PM2 is already the supervisor and the
ecosystem file is already the definition of how each process runs; a second thing in charge of that
means two supervisors disagreeing. It also means an owner can undo anything the app store did with a
command they already know. The one fact that matters: `pm2 start <name>` fails for a process PM2 has
never seen, so a first install starts from the ecosystem file with --only, and everything after goes by
name. Callers cannot know which case they are in, so startProcess decides.
Disable stops rather than deletes: a stopped process still shows in `pm2 list`, which is the honest
picture. Deleting would make a disabled sidecar indistinguishable from one never installed.
beginInstall returns the existing row instead of replacing it — that is what makes a retry a resume
rather than a re-provision — and clears lastError on the way in, so a UI never shows a stale failure
beside a working service.
The container half of enable/disable/uninstall is deliberately absent rather than stubbed silently: a
disable that leaves Immich running is a different thing from one that stops it, and the difference is
memory on the user's machine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Not sonnet, and not variant. Swept models through the new pipeline: every -free model runs,
every paid one silently does not — haiku, sonnet and codex-mini all never start.
Ruled out: variant (sonnet advertises low/medium/high/max and echoes back an invalid
"default", which looked like the answer and was not — setting high explicitly also never
ran); credentials (zen key in auth.json plus ANTHROPIC_API_KEY); and the sidecar environment,
since the same process runs sonnet fine through opencode run.
So the new pipeline does not resolve paid-model credentials and says nothing, while run and
the legacy path authenticate fine. Upstream bug in an in-progress pipeline, not our config.
The fork stays blocked, but precisely: steer and queue are proven, and the day a paid model
runs there the migration is worth doing immediately. Re-run the sweep after each upgrade.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Implements the half of the template contract that faces the platform: answers go in as environment and
never as prompts, and results come back as OFFICER_RESULT_<KEY>= lines on stdout.
A line protocol rather than JSON because the same stream is the user's live log — it goes to a terminal
panel while the install runs. A script that must emit clean JSON cannot also narrate, and one that emits
both needs a framing convention anyway. This mirrors the @@officer:progress@@ sentinel the job runner
already uses, with the same rule: marker lines are plucked out, everything else passes through.
parseResults is pure and tested against the realistic near-misses: a line that MENTIONS the prefix
without starting with it, an empty value (Transmission with no RPC auth returns exactly that, and blank
is a real answer), a value containing `=` (splitting on every one would truncate a credential), and a
prefix with no assignment (a script bug — skipped rather than stored as a blank key).
Verified end to end against a real script: environment reaches it, stderr is forwarded (docker compose
writes its progress there, so dropping it would hide most of what a user watches), OFFICER_NONINTERACTIVE
is set so a script that would block fails loudly instead of hanging behind a web form, and a non-zero
exit is reported with the tail.
Notes an artifact rather than hiding it: the two streams are pumped concurrently, so the error tail can
interleave differently from real time. The live log is correctly ordered; only the summary can read out
of order. Serialising the pumps would make a script that writes heavily to one stream block on the other.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Install spans a container start, a health wait, an upstream API call and a process start. Any can fail,
and one of them — a token only a human can mint — is EXPECTED to stop the run. A straight-line function
has two bad options there: unwind everything, or leave a half-installed service that neither works nor
uninstalls, which is the state users cannot get out of.
So each step is named, completion is persisted, and running install again resumes. planSteps is a pure
function of (entry, mode) and the effects are injected, which makes ordering, resume, blocking and
failure testable with no Docker, Postgres, PM2 or Immich in sight. 15 tests cover exactly the behaviour
that only appears when something goes wrong.
Two rules are enforced by the plan rather than remembered at call sites: 'existing' never provisions, so
pointing at an instance the user already runs cannot start a container; and the members step is omitted
entirely for a service with no user concept, so a Transmission install does not report a step that did
nothing — which reads as a silent failure to anyone debugging a member's access.
`blocked` is a first-class outcome, not an error. For Immich the container is up and healthy and only
its own UI can mint a key; calling that a failure would make a normal install look broken and invite the
user to tear down a working container. The blocking step is deliberately NOT recorded as complete, so a
resume re-runs the step the human just answered.
Results feed forward — provision discovers the URL that connect writes down two steps later — over a
copy of the caller's values, so a failure halfway cannot rewrite what an earlier attempt achieved.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Disable now stops the container as well as the sidecar. There is no reason to leave Immich holding
memory while Photos is switched off. For mode 'existing' there is no container of ours, so disable is
only the sidecar.
Uninstall stops both, removes the containers, and deletes the install row. It does NOT drop the
sidecar's tables — pushing back on "maybe db schema too" for the same reason volumes are kept, because
it is the same category. Music favourites, the Jellyfin server registry, photos configuration and saved
connections are real data, and someone uninstalling Photos is saying "stop running this", not "forget
which albums I favourited".
Keeping them also makes reinstall a RESTORE: uninstall in June, reinstall in August, and the
configuration is still there. Dropping the schema would hand back a blank service that looks subtly
broken to someone who remembers setting it up. An unused table costs a row in information_schema and
nothing else.
Also removes a line left stale by the previous commit, which still said the user chooses disposal at
uninstall time. There is no such choice any more, and a doc that describes an option the code does not
have is how the option comes back.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There is now no uninstall option that deletes data, rather than a careful one that does. A user
uninstalling a sidecar is saying "stop running this", which is not the same sentence as "delete my photo
library", and for Immich or Jellyfin getting that wrong once is unrecoverable. No confirmation dialog
makes it a good default.
So: `docker compose down` without `-v`. Containers and networks go; the service directory and everything
under it stays exactly as it was.
The bind-mount convention already makes this hard to get wrong, which is worth noting because it means
the safety is structural rather than a rule someone has to keep following. Data lives on the host inside
the service directory, so `-v` — which only removes NAMED volumes — could not delete it even if a future
change added the flag back.
`mode: 'existing'` has no disposal question at all: we did not create that service, so uninstall removes
our sidecar and our rows and touches nothing else.
Reclaiming disk becomes its own feature later, with the sizes in front of the user — "Photos is using
340 GB, delete it?" — as a deliberate act rather than a checkbox inside an uninstall flow.
Removed two stale `down -v` references that survived the first pass, one in the schema comment and one
in the design doc's table. Leftovers like those are how a rule becomes permission again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The owner installs, but a server may already have members, and a member added next month needs the same
work. So the unit is (service × member) reachable from two triggers — install a service, provision
existing members; add a member, provision installed services — rather than a loop inside the installer.
Only handling the first works on day one and rots.
No new table. A member is provisioned exactly when they hold a service_connections row: their own
credential, url NULL, inheriting the instance from the owner's. That schema anticipated this before this
existed, and a second record of the same fact would only be able to disagree with the first.
Three outcomes, declared per catalogue entry so the installer never special-cases a service. `accounts`
is fully transparent. `none` is a single-tenant daemon with nothing to do — filtered before the
provisioning loop so callers can tell "nothing to do" from "did nothing", which look identical at a call
site and matter when someone is asking why a member cannot see a feature.
`invite` is not a weaker `accounts`, it is the correct outcome: Vaultwarden derives its encryption key
from the master password, so a credential we could mint would mean a vault we could read. Transparent
right up to where being transparent would be a defect.
The per-service work is an interface implemented beside each sidecar rather than a switch in core — a
central function growing a case per service is what would stop any of this shipping from its own
repository. Implementations must be idempotent, since both triggers can fire for the same pair and a
duplicate account upstream is not ours to undo. Deprovision is optional and defaults to leaving the
upstream account alone: deleting an Immich user deletes their photos.
Written assuming the vault's multi-user adaptation has landed. Today /api/vault is owner-only by an
explicit ownerGate, so a member is refused before Vaultwarden is reached — verified, and out of scope.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Each provisionable service gets a directory holding a compose template and a setup.sh. Deliberately the
shape a sidecar needs once it lives in its own repository: metadata, compose, setup script, schema.
The contract (templates/README.md): answers come from the ENVIRONMENT, so the web form fills them in and
a person on a VPS is prompted only for what is missing, and only on a TTY — one script for both, not two
code paths. Idempotent, writes only inside its own directory, streams progress on stdout (the installer
pipes it to a terminal panel), and returns results as OFFICER_RESULT_<KEY>= lines so nothing has to
scrape a log.
House conventions throughout: relative bind mounts so data sits beside the compose file rather than
hiding behind `docker volume inspect`, containers running as the installing user so downloads are not
root-owned, loopback-only ports unless the service's whole job is inbound connections, and no external
networks — the owner's own composes attach to an `nginx` network that a fresh VPS does not have.
Transmission verified end to end on this machine, on non-conflicting ports, then torn down: renders,
starts, waits, reports. Its health check accepts 409 because Transmission rejects the first request by
design — only-200 would have waited out the full timeout against a working daemon. Re-run produced
exactly one container, and files landed owned by the user rather than root.
Vaultwarden covers the case where we GENERATE the credential rather than asking for one. An existing
token is reused, never rotated, because rotating during a resumed install would lock the owner out of
the admin page. The Argon2 hash has its `$` doubled or compose interpolation mangles it. The token is
not returned to the platform at all — the vault sidecar proxies the Bitwarden protocol and never needs
it, and a secret we do not hold is one we cannot leak.
Corrects the design doc, which assumed provisioning always knows the connection. Three shapes: we set
the credential, we generate it, or a human must mint it in the service's UI afterwards (Immich, Jellyfin,
Memos). The third makes "provisioned and running but not yet connected" a real state rather than a
failure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An install that discovers a missing dependency halfway through has already made a directory, possibly
started a container and written a row, and then has to unwind — leaving the user with something that
neither works nor uninstalls. A 30ms check first is worth most of that.
Verified while writing this: nothing in scripts/ installs Docker, and nothing checks for it.
setup-dockers.sh invokes `docker compose` with no preflight, so a fresh host without Docker fails
partway through setup with a bare "command not found". Recorded in the design doc rather than fixed
here — the intended fix is a setup.sh per sidecar, which is also what a sidecar needs once it ships from
its own repository.
`docker compose version` is the probe, not `docker --version`: the latter passes with a dead daemon,
which is the failure people actually hit. "Not installed" and "daemon unreachable" are reported
separately because the remedies differ.
Checked per MODE, not per entry. A host without Docker can still install Photos by pointing at an Immich
somewhere else; refusing the whole entry is the over-strict check that makes people work around the
installer instead of using it.
Dropped `requires: 'docker'` from the catalogue type. Needing Docker is exactly "this entry can
provision", which `modes` already says, so declaring it twice invites the two to disagree. Derived by
needsDocker instead, and a test asserts the derivation matches every entry.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The install layout a machine should have, seasoned owner or not:
~/officerdev/
platform/ the app
data/ DATA_PATH
dockers/ services the app store provisioned
capabilities/ the file-based item store
One root, everything under it. OFFICER_ROOT derives from DATA_PATH rather than being a second variable
that has to agree with the first.
Deliberately not `~/dockers`, where a seasoned user already keeps their own estate — 47 services on this
machine. That separation buys two things. Containers the app store created are distinguishable from the
user's own structurally, rather than by a naming convention we would have to enforce and they could
break. And we never reason about someone else's compose files: the store does not scan, adopt or modify
anything outside its own directory.
That also simplifies "I already have one of these" — it is answered by the user giving a URL, never by
us finding a directory and guessing whose it is. An earlier draft had the installer adopting existing
directories, which meant reading, and potentially writing over, services Officer did not create.
This development machine predates the convention and derives an ugly-but-correct path, since the project
sits inside ~/dockers/officer.dev. Still isolated, still one root. New installs get the clean shape.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First slice, on a worktree branch so none of it touches the tree the live server runs from.
`sidecar_installs` — server-level, no userId, because a sidecar is one process serving the machine.
That is the line that keeps the model coherent for several users: installed is server-level and
owner-only, configured is per user in service_connections. A member can use Gitea without being able to
install it or point it somewhere else.
`installed` and `enabled` are separate because they answer different questions, which is what gives the
reversible middle ground: disable stops the process and keeps container, config, schema and data.
`completedSteps` makes install resumable rather than merely retryable — the failure mode being designed
against is a half-installed service that neither works nor uninstalls.
The catalogue is data, not code: no functions, no compile-time coupling, because the same shape has to
arrive as JSON from marketplace.officer.dev later. Its test pins it to the real estate — it offers
exactly the processes the light profile excludes, names processes that exist, and claims capabilities
that exist. That last check earned itself immediately: it caught `vault` (no capability at all — it is
EXEMPT because Bitwarden clients carry a Vaultwarden bearer, not a platform JWT) and `notify` (which
does have one, where I had written null).
Docker templates follow the convention already in use across 47 services in ~/dockers: a directory per
service, compose inside, relative bind mounts so data sits beside it, USER_UID/USER_GID as the owner.
An existing directory is evidence of an existing install and must be adopted, never overwritten.
Records what Phase 0 must not foreclose: a remote marketplace, sidecars moving to their own
repositories, and third-party plugins — including the note that catalogue.test.ts pins Phase 0's
invariant rather than the design's, since that relationship inverts once sidecars leave this repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The previous commit migrated only when SQLite was completely empty, on the assumption that a non-empty
file is an authoritative one. A real account disproved that within minutes of it landing.
The older Gmail backfill had already written SOME keys into SQLite — last_sync_at and the uidvalidity
set — and never the imap_lastuid ones. So the file was non-empty and half-migrated at the same time,
all-or-nothing skipped the migration, and nine imap_lastuid keys stayed only in Postgres. A missing
lastuid makes the next sync refetch that folder from UID 1: on the mailbox this was found on, 18,755
messages and 6.9 GB.
Now merged per key with the file always winning a conflict. That keeps the property all-or-nothing was
protecting — a restored older emails.db still overrides a newer Postgres row for every key it has, so it
cannot be advanced past mail it does not contain — and adds the keys the file never had, which are
exactly the ones whose absence is expensive.
Verified against the live account: all 22 Postgres keys present afterwards, imap_lastuid:INBOX restored
to 208407, and last_sync_at left at the file's older value, so it re-checks a fortnight rather than
skipping it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
I concluded a few commits ago that the serve new /api/session pipeline accepts prompts and
never executes them, and kept turns on opencode run. Wrong. Every probe behind that passed
an explicit model claude-sonnet-4-6, and THAT model silently does not run on the new
surface — no error, no event, no assistant message. Drop the field and the same request
completes.
One broken variable in every experiment, read as a property of the system.
Measured on 1.18.16, both machines upgraded today: delivery steer injects into a running
turn (verified, output changed to order), delivery queue runs after it (verified, ONE then
TWO, zero errors), and model selection works via POST /model — just not with sonnet.
So the fork is reopened and worth taking, targeting the new surface rather than the legacy
message path, which generates fine but has neither steer nor queue. Blocked only on why
sonnet dies there while working under opencode run.
Third time this project has hit the same trap: opencode accepts input it does not honour
and says nothing — directory in the body, location.directory that never existed, now model.
A probe that changes one thing and sees nothing has not learned the feature is missing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The messages were in emails.db and the position — last_sync_at, and per-folder uidvalidity/lastuid —
was a jsonb column on email_accounts in Postgres. Two stores for one fact, with an edge that only shows
up when you try to move a mailbox to another machine.
The expensive part of an email account is the first sync: hours of IMAP for a large mailbox, which is
exactly why "copy emails.db to the new server" is the obvious way to bring one across. With the position
in Postgres that silently does not work — the new server's column is empty, !last_sync_at says first
sync, and the whole mailbox downloads again on top of the one just restored.
The other direction is quieter and worse. Restore an OLDER emails.db while Postgres holds a NEWER
position and the sidecar skips every message between the two, permanently, because nothing looks below
lastuid again. Re-syncing is slow; skipping mail is data loss nobody notices.
Not a new idea — the Gmail path already read SQLite and fell back to Postgres, backfilling so the
fallback was taken once. Only the IMAP path had not followed. This extracts that pattern so both use one
copy, and unifies the isFirstSync fork in accounts.ts, which is how the two drifted apart to begin with.
The file wins over Postgres, always, and only migrates when it holds nothing at all. Topping up a
partial position from Postgres would reintroduce precisely the divergence this removes.
email_accounts.sync_meta is kept and marked legacy rather than dropped: it is the one-time backfill
source for every account created before this, and dropping it would strand any that has not synced
since. Nothing writes to it now.
11 tests on the migration, aimed at both expensive failures — migrating when we should not, and failing
to migrate an account that predates the change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The serve has a second, newer API surface nobody here had looked at, and it publishes
exactly what the parity doc calls impossible under stdin ignore: delivery steer and queue
on POST /prompt, an interrupt that does not tear down, and a per-session event stream with
an after cursor — the durable-replay machinery officer hand-built for claude, as a
primitive. That would have made migrating obvious.
It does not execute. A prompt is accepted with an admittedSeq, stored, emits
prompt.admitted and prompted, and then never steps. Ruled out separately: the model, the
permissions (build is *:allow, no pending requests), the per-request location (the surface
is location-scoped via header or a deepObject query, supplied everywhere, no change), and a
config gate. The legacy POST /session/id/message?directory= generates fine in 17s, so the
serve itself works — only the new pipeline is inert. session.next.* is the tell.
And not a version problem, which is the part everything here had backwards: this Mac runs
1.18.11 and alpha runs 1.17.9, measured. The dead pipeline was tested on the NEWER binary.
The original "this server runs 1.17.9" meant alpha and was copied to a machine where it was
false; corrected in runner.ts and the test.
So building against it now would produce code that looks finished and does nothing, which
is the failure mode this project keeps rediscovering. One request reopens the question
after any upgrade, and the doc names it.
Also de-flakes the lifecycle tests: they spawn real processes, and a fixed sleep(750) went
red once on a machine busy running these probes. Presence assertions poll now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
They were permanently unnamed, and the two halves needed to name them already existed on
officer: the sidecar reports its own sessionKey because that is all it has, while the ses_ id
arrives separately over opencode:session and is recorded in opencode/state.ts. Nothing joined
them. /chat/live joins them now, so no protocol or sidecar change — widening
LiveOpenCodeSession would have meant sending the sidecar a fact it told officer in the first
place.
One list call names every row rather than one transcript load each, and it is skipped when
nothing is running or no id has been reported, so an idle Live panel never touches the serve.
Verified against a real turn, which also showed the design working as intended: the first
poll has no id yet and shows nothing, the next shows title and cwd. That window is real and
short, and showing nothing beats showing a key the user has never seen.
Worth knowing: opencode titles its own sessions "New session - <ISO timestamp>", so the row
is located but not meaningfully named. That is genuinely its title, not a bug here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B8 done, so every defect that made opencode behave wrongly is fixed. Notes what that does
not mean: bucket 1 is capability gaps, and the visible ones are downstream of the phase 2
fork, which is still unstarted and still Andre to call.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B8, both halves. They share index.ts, so they share a commit.
In-flight turns: `opencode run` is spawned, not supervised, so pm2 restart officer-opencode
left every turn ALIVE — reparented, still spending tokens, still writing files as the agent,
with the only reader of its stdout gone. The transcript stopped mid-tool-call, which reads
as the agent hanging.
stopAllOpenCodeTurns kills them and settles each synchronously, because the caller is about
to process.exit and nothing waiting on proc.exited would ever run. Settling writes a reason,
so a reload after a restart explains itself instead of trailing off. Turns are stopped BEFORE
the connection is destroyed — that write travels over it — and the flush is bounded, since
losing the explanation is bad but hanging the restart is worse.
Stale serves: the sweep read /proc, so it was a no-op on macOS and orphaned serves piled up,
one per unclean exit, each holding a port. Added a pidfile sweep alongside it. A pid we wrote
ourselves needs no cwd guard to prove it is ours, which is the part ps cannot answer portably
(macOS would need lsof), and a serve started by hand is never in the file.
The guard checks command AND subcommand: matching the word serve anywhere in the line would
sweep a running turn whose prompt merely mentioned it. Fixtures are real ps output from both
machines, not invented. Split into serve-sweep.ts because index.ts spawns a serve at module
scope, so a test importing it would start one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The bucket-0 table had no status anywhere; it lived in the report docs, which means the
list itself still reads as eight open defects. Says B1-B7 are done and where.
Also corrects B7 in place: the table describes the spurious cut-off only, and the same
default was mis-adopting the session into the wrong harness entirely.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B7. `msg.model || DEFAULT_MODEL` declared every session without an explicit model to be
claude-code, and the parity doc recorded only the visible half of what that cost.
The durable false cut-off is real: endTurnIfAgentIsGone asked the claude sidecar about a
key it had never held, was told false, and wrote "the agent went away" into a turn that
was running fine. It survives reload, because surviving reload is what that row is for.
The same default also handed the session to adoptOrphanedSession as a claude one, which
subscribes it to that sidecar bus and pins session.model — so an opencode turn output
never arrived, and stopping it called killClaude on a key that sidecar never had. A stop
button that silently does nothing.
decideResume makes both rules explicit: the server record beats the client claim, and an
unknown harness stays unknown — no adoption, no cut-off check, just the replay. Silence
is the safe failure when the wrong answer is written durably.
DEFAULT_MODEL stays in handleAttach and is now commented as to why: that path reached its
sessionId by asking the claude sidecar to resolve a claudeSessionId, so only claude could
have answered.
First test in api/chat, which had none. websocket.ts has no seam to drive the handler
through, so the decision is extracted and tested; the wiring around it is not covered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Agreed in conversation, nothing implemented. Light stops being a variant and becomes the baseline —
chat, terminal, file browser — and the other fourteen sidecars arrive by the user asking for them from
an app store, eventually including sidecars the user did not write.
Mostly not a rewrite, for three reasons already true: every API route stays mounted regardless of which
sidecars run, officer already spawns nothing, and service_connections already solves the multi-user
case. What is new is provisioning, per-sidecar schema, and persisted install state.
Docker: officer is the installer, never the owner. Real compose files in the user's own directory,
started as him, found again by label. `docker compose down` works, and the containers outlive Officer.
Per-sidecar schema is right here specifically because third-party plugins are a real goal, and the
dependency graph makes it tractable: measured across 19 schema files, every sidecar depends on auth.ts
and nothing else, with no sidecar-to-sidecar edges anywhere. So the plugin contract is "you may
reference users.id" — which also makes full uninstall well-defined, since nothing else points at a
plugin's tables.
service_connections stays core and shared rather than per-service, because it already does the part
nobody would get right alone: a NULL url means "inherit the instance", so the owner's row is the
instance and members hold only their own credential, making "members never see the instance URL" a
property of the schema instead of a filter someone has to remember.
Records six open questions rather than settling them, including plugin migrations, ID namespacing for a
marketplace, and where plugin-specific config lives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The review was written as a handover; it became a fixed tree instead. Records what
landed, including the two leaks that only showed up while fixing it, and leaves the
original reasoning untouched so it still reads as the argument it was.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two comments describing behaviour the code does not have.
LiveOpenCodeSession had been inserted between LiveClaudeSession and its docblock, so a
comment about isGenerating, pendingTasks and the idle GC read as documentation for the
OpenCode type — where it is contradicted by the correct comment directly beneath it.
Moved below, and it now states that it carries no ses_ id.
That absence is the point: /chat/live claimed title and cwd come from the session store
"so a turn whose id has not been reported yet shows unnamed". Nothing is looked up, and
there is no id here to look one up with. They are null permanently, not until-known.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A replaced turn is killed but dies asynchronously, so its proc.exited fired long after
the replacement was registered under the same sessionKey — and then ran the whole
completion path against it: emitted "OpenCode exited with code 143", which the sidecar
commits to chat_session_events so a false failure became permanent history, then deleted
the replacement from `running`. That blinded the new Live panel, made the stop button a
no-op and orphaned a process nothing could reach.
Mark the handle before killing it, retire it silently, and identity-check the delete —
a superseded turn does not own that key any more.
Two leaks in the same family, found while fixing it. An early return would not have been
enough: both watchdogs call finish, so the armed 10-minute hardTimer would have fired an
error at whichever turn held the key by then. And handleLine had no `done` guard, so
stdout still draining from the killed process was emitted under the replacement key.
Reproduced before fixing. The lifecycle tests need no real opencode — RunnerConfig.bin
takes a shell script that sleeps. The control test pins that an ordinary non-zero exit
still reports an error, so the guard cannot overreach.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ecosystem.light.config.cjs` did not mention officer-gitea, so `defineProfile` threw while the file was
being loaded and pm2 could start NOTHING from it — not the app, not the agent, not the terminal. The
profile has been dead on arrival since gitea was added to ecosystem.config.cjs and to the mac profile
but not to this one.
That is the drift check doing its job rather than a flaw in it: the alternative is a light install that
silently starts less than it claims. The cost is that adding a sidecar breaks every profile until each
one classifies it, which is the trade the file already documents.
Included rather than excluded, matching the mac profile's reasoning: this sidecar fronts a REMOTE Gitea
whose URL and token live in `service_connections`, so it installs nothing locally. That is the line
between it and the excluded sidecars, which supervise a local daemon or container.
Both light profiles now load and contain the same six processes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 1 accepted and phase 2 answered well. One real defect: the supersede path in
runOpenCodeTurn kills a stale turn without marking it, so the dead process late-fires
finish() against the turn that replaced it — committing a false "OpenCode exited" to
chat_session_events, deleting the live handle from `running`, killing the stop button
and orphaning the process.
Predates this pass; reported now because e8bd946 is what made the map load-bearing.
Reproduced with a stub binary rather than argued — the transcript is in the doc.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Investigation notes, written as they were gathered rather than after the fact. No code changes.
Covers how a sidecar comes into existence: PM2 peer, dials in to /api/sidecar/register, reports an
ephemeral port, officer proxies to it. Officer spawns nothing — the only startup problem left is
ordering, handled by waiting on a capability rather than failing the first request.
The finding worth having: `sidecar/claude/` is TWO processes, and they register as different sidecars.
`claude/index.ts` is officer-anthropic-proxy and registers capability `proxy`; `claude/user-instance.ts`
is officer-agent and registers capability `claude`. So `isConnected()` — defined as "a sidecar with
capability proxy exists" — means the Anthropic proxy is up, not the agent, which is not what the name
suggests. It has no callers today, so nothing is misreading it yet.
Marks what is unverified and what is still open rather than presenting the lot as settled: the
bind-read-release race in getFreePort, whether the `PORT ?? 5000` fallback is reachable, what a partial
boot looks like, and whether the sidecar-side boilerplate is worth factoring the way create-proxy.ts
factored officer's side.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Implementation report for whoever wrote opencode-parity.md and opencode-phase0-review.md: what landed,
the three places the specs were wrong and how the reproduce-first rule caught each, the three places I
deliberately did not follow them, and what is unverified.
Phase 2's blocking question is answered in full — the serve takes a per-request `?directory=`, so the
coupling is gone in both architectures. The migration is not started; that decision is framed in
opencode-serve-path.md and left open.
Flags `opencode:list` as the one new capability whose happy path is unproven, and B7 as newly more
masked: the B2 fix makes the client send `model` more reliably, which hides the spurious cut-off rather
than removing it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Live panel asked `claude:list` and nothing else, so a running OpenCode turn was invisible — the panel
claimed to show what the agent is doing and silently omitted half of it.
Adds `opencode:list` / `opencode:sessions` and merges both harnesses in `/chat/live`, asked in parallel,
each failing toward empty so one sidecar being down contributes nothing rather than breaking the panel.
The OpenCode row is deliberately thinner than the Claude one rather than faked into parity:
isGenerating always true — a subprocess exists only while it generates, so there is no "merely open"
pendingTasks always 0 — `opencode run` has no background-task concept; reporting a number would
suggest a capability that does not exist
title / cwd null — the session store is keyed on the `ses_…` id the runner reports, not on
our sessionKey, so an unreported turn shows unnamed rather than guessed
This is the incremental option from docs/opencode-serve-path.md — enumeration without moving turns onto
the serve, so it buys the Live panel with no warm sessions, no SSE loop and no lifetime questions.
NOT verified end to end: no OpenCode turn was running to enumerate, so the verb is wired and typechecked
but has never returned a non-empty list. See COMMS/BLOCKERS.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Path names: the serve's cwd is DATA_PATH/opencode_server, not opencode-sidecar. Two comments said
otherwise and would send the next reader to a directory that does not exist.
Version pin: the comment claimed "verified live against 1.17.9" as though that were a property of the
code. It is a property of whichever binary is installed, and this project already runs two — 1.17.9 here,
1.18.11 on the other machine. Says so now, and points at the test as the thing that actually enforces it.
Tests, the first on the OpenCode path. `runner.ts`'s NDJSON → ChatEvent mapping was described as pure and
untested; it was untested but not pure — it lived inside `handleLine` as a closure over `emit`, the
accumulated cost and a reported-session flag, so it could not be called without spawning a binary.
Extracted as `mapRunLine`, genuinely pure: line in, {sessionId, events, costDelta} out. The two concerns
that span lines stay with the caller, because they are not properties of a line — emitting the session id
exactly once, and accumulating cost across steps. Behaviour is unchanged.
11 tests over what the mapping forwards, what it drops and what it must not turn into NaN. The last one
matters: a missing `cost` on a step_finish would otherwise propagate NaN into the turn total.
Phase 1 is complete: dead code deleted (previous commit), comments corrected, tests added.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 1 item 7, done in the order the parity doc asks: read the dead design into a note, then delete it.
`docs/opencode-serve-path.md` records what `event-mapper.ts` and the SSE half of `client.ts` did, and
what a rebuild would want back from them — the delta model and tool-state transitions, which are exactly
parity Phase 3's token streaming rather than new work.
Deleted: `event-mapper.ts` entirely, and `subscribe`/the shared `GET /event` SSE loop, `createSession`,
`postMessage`, `abort` from the client, plus `isServerHealthy` from server-manager. All had no callers.
`client.ts` goes 200-odd lines to 99. What stays is the REST reads the chat list and transcript use:
listSessions, getSession, getMessages, deleteSession, renameSession.
While in there, Phase 2's blocking question turned out to be cheap to settle, so it is answered rather
than left open. The review asked whether the serve can take a per-request directory, since without one a
serve-based turn path would reintroduce the single-directory coupling that shelved this work:
POST /session?directory=/tmp/oc-phase2-probe -> directory: "/tmp/oc-phase2-probe" honoured
POST /session with directory in the BODY -> directory: "<serve cwd>" ignored
It is a query parameter on every /session* route. So the coupling is gone on both architectures and the
blocker is cleared. The note does NOT start the migration: which of the three options to take is a
product call, and it lays them out rather than presuming one.
The first probe put `directory` in the body and appeared to prove the opposite. Recorded in the note,
because it is the obvious way to test this and it gives a confident wrong answer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The sidecar seeded an AGENTS.md into the serve's project root telling the agent to read its working
directory from the "Working directory for this session" line in its system prompt. The run path sends no
system prompt, so there was no such line and the instruction had been inert since turns moved off the
serve to `opencode run --dir`.
What it was standing in for, `--dir` does properly — tested rather than assumed
(docs/opencode-phase0-review.md): `--dir` anchors the agent's own file operations, not just the process
cwd, and the anchor survives a multi-step turn with a write in the middle. Nothing replaces it.
The generated file is removed from disk too, not only from the code that wrote it; leaving it would have
kept feeding standing instructions to every session while looking, in the source, as though it were gone.
Also corrects the claim that all OpenCode sessions live in one server's project. True when turns
inherited the serve's directory, false now: one serve lists 7 sessions across several directories, which
is why the cwd filter has to read `directory` rather than assume a single one.
docs/opencode-phase0-review.md, item 2 — Phase 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Regression from the fold change. Scroll-up paging is driven by a scroll listener, and a scroll listener
only fires on a list that actually scrolls. That was always true and never mattered, because the turn you
were looking at rendered in full and was tall enough on its own.
Folding on reload broke it. A window of twenty messages can be one turn with eighteen tool calls, which
collapses to three short rows: no overflow, no scroll event, and paging never starts. The whole
transcript above becomes unreachable — which reads as lost history rather than as a fetch that never
fired.
So don't wait for a scroll that cannot happen: after each render, if there is more to load and the
content does not overflow its viewport, load the next page. Terminates because each pass either fills the
viewport or exhausts the transcript.
This also fixes a latent case that predates folding — any first window short enough to fit on screen
could never be paged past.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reopened B4. Flipping `images: false` for OpenCode models made the metadata honest but changed nothing
on screen, because no code read the capability: the drop zone, the paste handler and the attach menu all
accepted images on every harness. The lie B4 described — drop a screenshot, watch it render in your own
bubble, have it discarded before the model sees it — was still there.
The flag is now load-bearing. Three entry points gated on `supportsImages`:
- the drop zone does not claim the drag at all (no highlight, no preventDefault), so the browser keeps
it rather than the composer swallowing a file it will drop on the floor
- an image paste falls through to the default
- the attach menu's Image entry is absent
`selectedModel || model` mirrors ModelSelector's `displayModel`, so the gate and the model name on screen
can never disagree. An unknown model allows images: a missing capability should not remove a working
control, and the flag is only false where we know it is false. Nothing to undo when images are plumbed
through OpenCodeRunParams later — the gate stops firing once the capability is true.
docs/opencode-phase0-review.md, item 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5