Files
openchamber/plans/opencode-v1.17.12-sdk/handovers/session-1.md
T
Leonidandbashrusakh 01a52eccab SDK v1.17.12: session.permission — programmatic create/fetch, more reliable auto-accept (#1982)
* docs: add SDK v1.17.12 migration plan — phase 4 (session.permission)

* feat(permissions): verify pending permission before auto-accept via SDK v1.17.12

Adds createPermission() and fetchPermission() wrappers on OpencodeService
for the new v2.session.permission endpoints (OpenCode SDK 1.17.12).

fetchPermission() is used by the auto-accept sweep in
resyncBlockingRequestsForDirectory to verify a permission is still
pending before replying. The auto-accept flow now skips permissions
that are already resolved, returning a null from fetchPermission()
rather than blindly calling respondToPermission on a stale entry.

createPermission() is exposed for future programmatic permission
creation; the V1 list/reply path used by the UI is unchanged.

The plan doc at plans/opencode-v1.17.12-sdk/ was rebased onto
origin/main in the prior commit to keep the PR diff focused on
this change.

Closes #1972

* fix(permissions): drop confirmed-resolved permissions from auto-accept resync

fetchPermission() now returns a tagged FetchPermissionResult so the
auto-accept loop can distinguish a server-confirmed 404 (the
permission is no longer pending) from a fetch failure (network error
or pre-v1.17.12 server). Previously both cases collapsed to null, so
a permission the server had already answered would still appear in
the resync output and trigger a spurious 'Permission needed' toast.

The auto-accept loop in resyncBlockingRequestsForDirectory now tracks
both accepted and resolved permissions, then drops both from the
'grouped' map before it falls through to the toast path. On a
pre-v1.17.12 server (no V2 endpoint) the call still returns
'unknown' and the permission stays in the resync output so the user
can answer manually — fail-closed, no false-resolved signals.

Adds a focused unit test for fetchPermission (4 cases: 200 ok, 404
resolved, 500 unknown, network throw) mocking the V2 SDK client
shape.

---------

Co-authored-by: bashrusakh <bashrusakh@users.noreply.github.com>
2026-07-11 16:11:13 +03:00

1.5 KiB

Handover — Session 1 (2026-07-01)

Current state

Plan created for OpenCode v1.17.12 SDK migration. No code changes made yet.

What was done

  1. Verified SDK v1.17.9 types against v1.17.12 release notes
  2. Identified 3 actually-new methods: session.interrupt(), session.events(), session.permission
  3. Identified 2 existing-but-unused: Session3.messages() with cursor, Session3.message()
  4. Created 4-phase plan with implementation details
  5. Created 4 GitHub issues (#1968, #1969, #1971, #1972)
  6. Created 4 draft PRs (#1973, #1974, #1976, #1977)
  7. Answered bot questions on all issues

Key findings

  • session.interrupt() is the highest-impact change — fixes abort propagation to upstream provider
  • session.events() and session.permission must be verified in SDK types before implementation
  • Session3 API has different parameter shape than Session2directory is client-scoped, before replaced by cursor
  • global.event() is already used correctly — no changes needed
  • Custom WebSocket/SSE in event-pipeline.ts is OpenChamber-specific (coalescing, routing, backpressure) — not a replacement for SDK

Next safe action

  1. Bump @opencode-ai/sdk to ^1.17.12 and run bun install
  2. Verify new SDK types exist (session.interrupt, session.events, session.permission)
  3. Start Phase 1: replace session.abort()session.interrupt() in 3 call sites

Blockers

  • SDK v1.17.12 must be published and installable
  • session.events() and session.permission existence unconfirmed