Skip to content

chore(fleet): align opencode build revs across laptop service, laptop CLI, sandbox CLI #1362

Open

Description

@dezren39

Observed in the access-pattern benchmark (code#1344), 2026-10-27: three fork build revs in simultaneous play — laptop background service 2.0.30+e7baa0d, laptop CLI 2.0.30+56590c5, sandbox CLI 2.0.30+954ff7c. The only signal is a stderr version-skew warning on opencode run --server ('Continuing anyway'). Mixed revs make behavior reports (hangs, event protocol, tool quirks) hard to attribute — two workstreams burned time tonight on symptoms that may be skew-related.

Work: pin one rev across the laptop home-manager build (service + CLI) and the sandbox nix profile; add the running rev to the fleet's standard health/readout surfaces (service status + quota/aggregator health) so skew is visible before it is debugged; note the pinned rev in the opencode tools doc when it changes.
Acceptance: service + both CLIs report the same rev; a forced mismatch is visible on a health surface without running a command by hand.

Acceptance criteria

  • Laptop background service, laptop CLI, and sandbox CLI all report the same opencode build rev.
  • The running rev is visible on a standard fleet health/readout surface (service status and/or quota/aggregator health), so a forced mismatch is visible without debugging.
  • The pinned rev is noted in the opencode tools doc, with the note updated when the pin changes.

Activity

  1. developing-today commented on Oct 27, 2026

    @developing-today
    Contributor
  2. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    Intake review

    Three fork build revs in simultaneous play make behavior reports hard to attribute; two workstreams already burned time on possibly skew-related symptoms. Suggested approach: pin one rev in the laptop home-manager build (service + CLI) and the sandbox nix profile, and surface the running rev on the health/readout surfaces named in the issue.

    Related: Related: #1344 (benchmark that observed the three-rev skew: service 2.0.30+e7baa0d, laptop CLI 2.0.30+56590c5, sandbox CLI 2.0.30+954ff7c). Labels normalized by fleet monitor: the issue arrived with only meta/follow-up.

    Still live: checked this run — no merged PR in the recent merged list of this repo implements or resolves this issue, and no closing reference was found; the issue stays open.

    🤖 Agent note · filed

  3. added
    kind/infrastructureInfrastructure / host-portability work
    priority/normalOrdinary priority (the default)
    effort/sSmall: expected under 2 hours of work
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 27, 2026
  4. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    Pickup: Claimed triage task 2567 in the OpenChamber scheduled lane. Checking current ownership and evidence before routing.

  5. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed on Nov 1, 2026
  6. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    Triage: Open; route a follow-up, not a claim that all three runtime versions currently differ. On main d64e83c10159445aa0def8625f725595b80ac888, the root flake's OpenCode input is locked to 855ec25f53e2b2a28ef2ffe2ceac396db2bfc753 (flake.lock, root opencode -> opencode_2); the NixOS environment installs that input and OpenChamber follows it. That pin does not prove an already-running external server or the sandbox CLI are running it. TOOLS.md describes the shared server/build but does not record the pin, so the documentation acceptance criterion remains unmet at this HEAD.

    The execution environment did not provide the opencode or systemctl commands to the probe; no laptop service/CLI or sandbox runtime parity, forced-mismatch test, or health-surface display was verified. Follow-up should inventory those three actual revisions, establish the correct owning repo/host for any pin changes, and add/test a readily visible mismatch indication and pin documentation without assuming a source lock proves runtime state.

  7. 4 remaining items

  8. added
    mode/onlineFully doable remotely: design, config, code, cloud
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    on Nov 1, 2026
  9. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    Pickup: Claimed queue task 5007 in the OpenChamber scheduled lane. Revalidated #1362 as open and found no issue-specific open PR; checking actual laptop runtimes and ownership before making changes.

  10. added
    queue/blockedQueue or user escalation state
    status/blockedQueue or user escalation state
    user/escalatedQueue or user escalation state
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 1, 2026
  11. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    Blocked / escalated: Queue task 5007 is blocked pending access to the sandbox CLI host, or a fresh read-only opencode --version result and the owning configuration path.

    Verified on laptop: opencode --version is v2.0.30+6fb3bac; the running service PID 1408640 uses /nix/store/9hwhqsw2ax892mjg99mx9n7k6jy49dj1-opencode-2.0.30+6fb3bac/bin/.opencode-wrapped on 127.0.0.1:13420; developing-today/code flake.lock resolves root opencode to 6fb3bacf37a4c374bf2c26c2a3cd64a0e223606a. These laptop revisions match.

    Blocker: No sandbox peer is online in Tailscale (the codex-environment peers are offline) and no SSH host alias is configured. Therefore the sandbox revision, mismatch health-surface behavior, and cross-host configuration owner cannot be established safely.

    Resume when: the sandbox CLI host is reachable or its current version/config ownership is provided; then compare all three revisions and proceed with the health-surface and documentation acceptance criteria.

  12. added
    queue/queuedHas a queued task in the Supabase agent queue
    and removed
    status/blockedQueue or user escalation state
    queue/blockedQueue or user escalation state
    on Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

effort/sSmall: expected under 2 hours of workkind/infrastructureInfrastructure / host-portability workmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedmeta/follow-upFollow-up spun out of earlier workmode/onlineFully doable remotely: design, config, code, cloudpriority/normalOrdinary priority (the default)queue/queuedHas a queued task in the Supabase agent queueuser/escalatedQueue or user escalation state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions