pastilhasandClaude Opus 5 547662842b a dead claude process no longer hangs the chat forever
the sdk runs two independent tasks per session: the consumer loop
(`for await (const msg of q)`) and an input pump that writes the queue to
the child's stdin. the consumer loop's `finally` is what removes a session
from the map — but when the CHILD dies it is the input pump that fails,
with `ProcessTransport is not ready for writing`, and that rejection
neither ends the consumer loop nor is caught anywhere.

so the loop stayed parked on a stream with no writer, `finally` never ran,
the session stayed in the map, and spawnClaudeStreaming handed every later
turn to the same corpse. each one pushed a message onto a queue nobody
drained: no error, no result, no timeout. the client spun forever and the
only trace was one unhandledRejection line in the sidecar log.

observed on the host today; the only cure was pm2 restart
officer-claude-code.

a member's turn already supplied its own spawn function because it has to
go through setpriv. the owner had none, and therefore no place to observe
the child — which is exactly why its death was invisible. so give the owner
one too, and wrap both in watchChild: on exit or error, drop the session
from the map and, if a turn was in flight, tell the client.

emitting only while generating is deliberate. a child that exits between
turns is invisible to the user, and an error bubble arriving in a chat
nobody is looking at would be noise — dropping the map entry is the whole
repair there, because the next turn builds a fresh session and resumes the
transcript by id.

the stall timer now tears the session down as well. it used to keep it —
"it may still be working, and the next turn resumes it" — which is right
for a slow agent and wrong for a wedged one: the session stayed broken, so
every later turn hung the same way and "send again to continue" was a lie.
sessions with background tasks outstanding are still left alone, since a
job can be silent far longer than ten minutes and still land its
notification.

verified live against the real manager: killed the child mid-turn, saw the
error surface and the next turn rebuild the session.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 15:36:09 +00:00
2026-02-16 19:34:35 +00:00
2026-02-16 19:34:35 +00:00
2026-02-16 19:34:35 +00:00
2026-02-22 03:35:26 +00:00
2026-02-16 19:34:35 +00:00
2026-02-16 19:34:35 +00:00

The documentation, triaged

2026-08-13. A map of what is in here, what it is for, and what should happen to it. Made because there are 42 documents and 13,000 lines, and no way to tell from the filenames which describe the system as it is and which are a record of an afternoon in July.

How much I verified: the classifications below are from filenames, status lines, and greps for things that changed on 2026-08-13. Where I actually read the document or checked the code, it says so. The rest is a starting point for a conversation, not a verdict.


Living — these describe the system and must stay true

doc state
working-on-officer.md updated 2026-08-13. Operational guide.
secret-store.md updated 2026-08-13. Built; rotation still open.
install-variants.md new. The branch tree, for discussion.
http-secure-context-audit.md new. What breaks over plain http.
install-container-testing.md new. First container pass and its findings.
per-user-linux-accounts.md partly updated. OFFICER_OS_USERS is gone; check the rest.
navigation-audit.md authoritative on routing. Unverified against tonight's route removals.
workspace-panels.md + workspace-panel-todo.md the panel framework. 1,300 lines combined — likely the biggest cleanup here.
agent-coordination.md the north star for panel work.
deprovision-os-account.md implemented; the 'disabled' stage it may mention was deleted tonight.

Stale — describe things that changed on 2026-08-13

Each of these references something that no longer exists. Not yet corrected.

  • sidecar-topology.md — "ecosystem.config.cjs is the source of truth". It is generated now, and holds six processes.
  • sidecar-app-store.md — derives the catalogue from full light. Those files are gone, and catalogue.test.ts was rewritten.
  • sidecar-bootstrapping.md — "20 PM2 entries, 18 sidecar dirs". Six entries now.
  • mobile-api-keys.md — partly corrected; recheck the origin-checking claims.
  • wallet-key-custody.mdVAULT_STORE_KEY is now the per-purpose wallet key.
  • push-notifications.md — "agreed design, 2026-07-31". Notify is a plugin and unmounted.
  • chat-session-lifetime.md, chat-ui-walkthrough.md — reference officer-agent, renamed.

Historical — a record of a moment, and should stay one

Do not rewrite these to match today's code. They document how a decision was reached, and editing them destroys the reasoning. If they mislead, add a dated header pointing forward.

  • sidecar-audit-2026-07.md (1,377 lines)
  • claude-sidecar-isolation.md — records the officer-claudeofficer-agent rename that preceded tonight's officer-agentofficer-claude-code
  • open-threads-after-per-user-claude.md
  • two-agent-field-report-2026-08-12.md
  • api-method-changes-2026-08-06.md

The opencode cluster — nine documents for one migration

opencode-fork-decision · -parity · -api-2-assessment · -phase0-review · -phase1-report · -phase1-review · -serve-migration-plan · -serve-path · -testing-checklist

The migration landedopencode serve is in the sidecar, verified. So opencode-serve-migration-plan.md saying "Nothing here is implemented" is false.

This is the clearest consolidation candidate in the whole directory: one document recording what was decided and what shipped, replacing nine that describe stages of getting there. I did not do it because it needs reading all nine, and deleting documents unread is not a thing to do at 4am.

The mobile-dav thread — three documents, one conversation

mobile-dav-provisioning · -feedback · -reply. A correspondence. Almost certainly one document.

Unclassified — I have not looked

design-language-interface · file-sync · jobs-unification · mobile-photo-sync-api · nextcloud-replacement · agent-git-identity


The plugin split, which affects most of the above

A core install is six processes. Everything else is a plugin, switched off tonight but present on disk. Most documents here were written when the estate was twenty processes and every one of them was simply "there", so they describe availability that no longer holds.

The useful rewrite is usually one line, not a rewrite: say whether the thing described is core or a plugin, and if a plugin, that it is not mounted on a fresh install.

S
Description
No description provided
Readme
42 MiB
Languages
TypeScript 90.9%
Shell 4.7%
JavaScript 4.1%
CSS 0.2%
HTML 0.1%