Skip to content

Refresh the upstream pin to v2.0.32 #462

Open

Description

@Blind-Striker

Move the SDK's OpenAPI pin from opencode v2.0.29 to v2.0.32 (843a6c514e606b436a7fe713422ace0a93ad3d61), following spec/SNAPSHOT.md's refresh procedure. The maintainer's machines already run opencode 2.0.32, so until this lands the SDK pin trails the servers it talks to.

What moves at v2.0.32

  • Operations: 142 → 143. The one addition is experimental.voice.session (POST /api/experimental/voice/session); none are removed or changed.
  • The Restore patch 001-restore-sse-payloads still applies.
  • Watched sources: 11 hashes move, and every anchor still matches.
  • Schema:
    • a new Config.Model.Reasoning union, keyed by supported: false|true;
    • reasoning and temperature on the config model capabilities, and temperature on the model capabilities;
    • releaseDate on Config.ModelEncoded;
    • eight Voice* components.
  • Windows: the default service port becomes 45278 (0xB0DE).

Scope

  • PR A, generator (feat(generator): an optional special number keeps its named literals through the tri-state wrapper #459): an optional-and-nullable request member whose number admits NaN and the infinities gets a working tri-state converter. Today generation crashes on VoiceWebRTCTransportInput.dcid with "No optional converter name exists for plan 'SpecialNumberTypeReferencePlan'".
  • PR B, the refresh itself (chore: refresh the pin to upstream v2.0.32 #465; its base contains feat(generator): an optional special number keeps its named literals through the tri-state wrapper #459):
    • refresh-spec --ref v2.0.32, a reviewed receipt, then --apply;
    • the voice door: CreateVoiceSessionAsync in the Experimental client, carrying its experimental diagnostic like the other upstream-experimental doors; the Voice* types in the Experimental slice;
    • reasoning names: the union's arms are ConfigModelReasoningUnsupported and ConfigModelReasoningSupported;
    • every new curated summary cites its upstream declaration at the pin;
    • secrets: confirm VoiceWebSocketTransport.token is masked in ToString();
    • regeneration and the public API baselines;
    • env precedence, wording only: the service-config env overlay stays. ServiceElection.OverlayAsync's summary and docs/guide/connection-modes.md say that the caller's entries win at spawn, and that inside a 2.0.32 server the saved env is re-applied for everything read after startup;
    • the test harness's real-daemon port guard covers 45278 as well as 49374;
    • a CHANGELOG [Unreleased] entry: the pin, the voice door, the new members and the env-precedence change.
  • After PR B merges: the distributed-build consumer leg on the merge commit (spec/SNAPSHOT.md step 5).
  • A follow-up PR from the runtime lane: a characterization test of the 2.0.32 env precedence, against a run-root-isolated service.

Decisions

Maintainer decisions, 2026-10-17: the voice door is CreateVoiceSessionAsync in Experimental; reasoning is curated to Unsupported/Supported; the service-config env overlay stays, and only the precedence wording changes.

The overlay stays because, at v2.0.32, the CLI's ensure path still injects service.json env at spawn. The new Object.assign(process.env, config.env) in packages/cli/src/server-process.ts:75 runs on every service-mode start (its comment names Desktop launches as the motive), but only after bootstrap has read its startup keys. So the injected env still decides those keys, and dropping the overlay would have added a divergence (ADR-0031). For everything read after that line, the saved env wins.

Activity

  1. Blind-Striker commented on Oct 18, 2026

    @Blind-Striker
    CollaboratorAuthor

    D32-1 (EPERM when XDG_STATE_HOME equals XDG_CONFIG_HOME): the docs line landed in #475. The SDK adds no guard, since that would diverge from upstream. Reported upstream as anomalyco/opencode#56746, with a plain-CLI repro: 4/30 with one root, 0/30 with separate roots.

  2. added this to the 1.0 milestone on Oct 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dependenciesPull requests that update a dependency file

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions