Repository navigation
Pilot: OpenChamber session API inventory for a remote babysitter #1188
Description
Pilot — information gathering for the OpenChamber babysitter
Question: what can a babysitter process actually read and do against
the laptop's OpenChamber/OpenCode stack, programmatically, from a
different host?
Gather and document (in the fleet goal workspace, linked from this
issue):
- Session list/inspect endpoints: fields available per session (id,
title, status, directory, created/updated, last activity, current
model/provider, parent/child sessions). - Message injection: how to send a follow-up message into a running
session (the babysitter's nudge), and how to create a session bound
to a project directory/worktree. - Auth: what credential the babysitter needs, where it lives
(Bitwarden name only in the doc — never a value), and whether the
sandbox can reach the laptop endpoints (Tailscale) with acceptable
latency. - Gaps: anything the babysitter design needs that the API does not
expose (e.g. per-session token usage, pool attribution) — name each
gap and a workaround if one exists (session metadata written at
dispatch time is an acceptable workaround; record it as such).
Acceptance criteria
- An inventory doc exists listing endpoints + fields, verified by
live calls against the laptop stack (not from docs alone). - A babysitter-host process on the sandbox lists the laptop's
current sessions and reads one session's activity end-to-end. - Every design dependency on the API is marked confirmed or gap,
with the workaround named for each gap.
Part of the OpenChamber dispatch + babysitter design (2026-10-26).
Filed by Muse (operator) 2026-10-26.
Activity
developing-today commentedon Oct 27, 2026
CODE-324
dezren39 commentedon Oct 27, 2026
Pilot progress — first-pass inventory done (2026-10-26 late).
Doc:
files/openchamber-api-inventory-2026-10-26.mdin the keep-the-four-repos-healthy goal workspace.Confirmed live: the laptop runs OpenChamber 2.5.0 (:3000, localhost + Tailscale) managing per-project OpenCode servers on dynamic authenticated localhost ports — a babysitter integrates at the OpenChamber API layer, never at those ports. Key surfaces found in the fork's web server and spot-verified:
/api/session,/api/session-activity(the progress feed),/api/quota/*(providers list answers locally),/api/project-context/:id/{plans,todos}(plans bind to sessions — the dispatcher's binding shape), plus OpenChamber-native scheduled tasks the design must reconcile with.routing.jsonholds OpenChamber's own route categories (trivial/research/implement/hard) — the tier policy maps onto these.Remaining gaps keeping this pilot open: per-session fields from a live session (none were active during the probe), the paired-client auth flow for a sandbox babysitter over Tailscale, and the exact nudge (message-injection) call shape verified against a running session. Those land with pilot #1191's live runs.
1 remaining item
dezren39 commentedon Oct 27, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 27, 2026
🤖 Agent note · done
repo-health:v1:maintenance:developing-today/code:oc-api-inventory-1188-verify:2026-W44(not_before 2026-10-29T00:00Z)Triage verdict — scope confirmed; route is the live babysitter system; three verification remainders ride on #1191
Verified fresh this run (2026-10-27):
files/openchamber-api-inventory-2026-10-26.mdin the fleet goal workspace, from the 2026-10-26 first-pass probe (progress comment on this issue, 2026-10-27T04:24Z): OpenChamber 2.5.0 on the laptop (:3000, localhost + Tailscale), per-project OpenCode servers on dynamic authenticated localhost ports, babysitter integrates at the OpenChamber API layer (/api/session,/api/session-activity,/api/quota/*,/api/project-context/:id/{plans,todos}).openchamber-babysitter(every 20m) andopenchamber-dispatcher(every 30m) are enabled and running, andhidden_files/babysitter-log.mdshows current rounds reading session activity and rendering per-session verdicts. The system this pilot was gathering information for exists and operates.Route chosen: keep #1188 OPEN (not Drew-blocked; no escalation), with a dated verification follow-up: packet
repo-health:v1:maintenance:developing-today/code:oc-api-inventory-1188-verify:2026-W44enqueued torepo-health-code-pilot,not_before2026-10-29T00:00Z, to confirm-or-gap the three remainders from #1191's live-run evidence and close this issue. Labels reset toqueue/queued(the follow-up is now its live work order) as this triage completes.dezren39 commentedon Oct 30, 2026
🤖 Agent note · done
Verification verdict — all three remainders dispositioned (2026-10-30)
1. Per-session fields from a LIVE session — CONFIRMED.
The babysitter has run live rounds every 20 minutes since 2026-10-27 (
hidden_files/babysitter-log.mdin the goal workspace). Today's rounds record live sessions with the full field set this issue asked for — e.g. the 17:0x CDT round: sessionses_e5e7132a88bffei9VuT2uQeMMt(#1018 / queue task 3992, status succeeded, model muse-direct muse-spark-1.3-contributor with final-turn content read end-to-end),ses_e5e713e9930ffeqE48Q1vkPa97(busy, opendesign deepseek-v4-flash) plus its README-table child session, and per-session bound task/issue, status, last activity, and pool attribution throughout. Acceptance 2 (a babysitter-side process enumerates the laptop's sessions and reads activity end-to-end) is satisfied by these rounds daily.2. Paired-client auth flow for a sandbox babysitter — GAP, workaround in production.
The paired client is NOT enrolled: #1271 is still open, and the inventory stands — remote programmatic access is a paired client via
/api/client-auth, not a static token, and it has not been exercised end-to-end. Workaround (the babysitter instruction's Access section, in force since v1): reads execute on the laptop over~/tools/laptop-ssh.shagainst the OpenChamber API at its Tailscale address (100.99.113.103:3000from off-laptop contexts); credentials are referenced by name only everywhere. Dated follow-up: #1271.3. Nudge (message-injection) call shape — GAP, no workaround yet, not blocking reads.
Still unverified: the babysitter log states "the nudge injection shape remains unverified" in round after round through today, and no nudge has ever been sent (no confirmed stall has yet had a live bound session, and both the nudge and finished-session-restart paths are explicitly gated on this verification in the babysitter instruction). The route exists in the proxy family (inventory gap 4). Dated follow-up filed today: #2870, with the implementation packet enqueued as queue task 4053.
Pilot acceptance: the inventory doc exists and is live-verified (acceptance 1); a babysitter process enumerates sessions and reads activity end-to-end (acceptance 2, via the named SSH workaround); every design dependency is now marked confirmed or gap-with-follow-up (acceptance 3). Closing this pilot as completed; the two open gaps live on as #1271 and #2870, which is where the work now is.