Repository navigation
OpenCode 1.18.32 Pin Re-verification (opencode_cli) #612
Description
As a SkillSpector user on current OpenCode, I want the opencode_cli deny-all policy re-verified against each new CLI release so the version gate keeps me safe without stranding me on an old binary.
The gap
The merged provider fails closed on anything but exactly 1.18.31. OpenCode 1.18.32 is out, so latest-version users get a refusal instead of scans — correct behavior, now needing re-verification.
What I am asking for
Please consider a re-verification bump: confirm identical flags/behavior, move the pin and all version references, and prove it with the existing gates plus a live self-scan. Done when the provider runs green on 1.18.32 with no policy changes.
This could be achieved by
- Bumping
_OPENCODE_SUPPORTED_VERSIONand all version references (comments, fixtures, README pin note, DEVELOPMENT) - Re-running provider suites, lint, and a live self-scan on the new release
- Note: full provider-path inference stays blocked by the known isolation × auth limitation (pre-existing, version-independent); the version gate,
--helpparity, and raw inference are the live evidence for this bump
Activity
rng1995 commentedon Sep 23, 2026
Re-verification is in progress in PR #613, which proposes updating the verified OpenCode runtime pin to 1.18.32 while retaining the deny-all policy. The PR is open and has not merged, so this issue remains open until the compatibility/security validation is accepted and the pin update lands.
feat(providers): verify OpenCode 1.18.32 for the deny-all policy
rng1995 commentedon Oct 4, 2026
Resolution update: PR #613 merged the OpenCode 1.18.32 verification/pin update. It was subsequently superseded by merged PR #665 for 1.18.33; the current provider still uses an exact verified pin and deny-all runtime checks. Offline provider regressions pass on current
main.This issue remains completed. The separate multi-version range request is tracked in #712 / open PR #713.