You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an OpenCode user on any recent 1.18.x, I want SkillSpector to accept my CLI version so a patch release does not break my scans.
The gap
The provider exact-pins one version, so every upstream patch release locks out users until a new pin PR lands. The runtime debug config resolved-subset check is the load-bearing safety net and already re-verifies the deny-all policy per invocation; the version gate is belt-and-suspenders and can be a range without weakening fail-closed.
What I am asking for
Please consider accepting any 1.18.31 <= ver <= 1.18.34: keep rejecting prereleases and unparsable output, keep both gates (preflight + auth check) plus the debug config subset check. Done when users on any of the four versions get scans and anything outside the range still fails closed.
This could be achieved by
Replacing the exact-pin string with inclusive MIN/MAX triplets and one shared range predicate used by both gates, with error messages printing the range
Adding boundary tests (accept .31-.34; reject .30, .35, prerelease, garbage, empty) and proving the matrix live per version
Widening MIN/MAX with appended matrix rows on future bumps, rather than overwriting the pin
The version-range proposal is in the open PR #713, covering inclusive OpenCode 1.18.31–1.18.34 while retaining version rejection and runtime deny-all checks. Merged PR #665 currently updates the exact pin to 1.18.33; it does not provide the requested range. Keeping this issue open.
Activity
rng1995 commentedon Oct 4, 2026
The version-range proposal is in the open PR #713, covering inclusive OpenCode 1.18.31–1.18.34 while retaining version rejection and runtime deny-all checks. Merged PR #665 currently updates the exact pin to 1.18.33; it does not provide the requested range. Keeping this issue open.
PR-state snapshot checked on 2026-10-04:
Keeping this issue open: the relevant implementation is not merged. Check/review status is a point-in-time snapshot, not a claim of merge readiness.