fix(agent): pin OpenCode to 1.15.13

[marcusrbrown]

Lifts the OpenCode pin from 1.14.41 to 1.15.13.

The pin was held at 1.14.41 because 1.14.42+ regressed /event SSE SyncEvent delivery — message.part.updated, message.updated, and session.next.* stopped reaching bus.subscribeAll() subscribers, which broke visible tool-call output in the harness. That regression was fixed upstream (anomalyco/opencode#27959) and is present in 1.15.13.

Verified against an isolated 1.15.13 server: the harness renders both tool-execution lines and assistant text end-to-end through the existing message.part.updated handler.

1.15.13 shifts the event contract — the tool lifecycle and text now arrive via message.part.updated / message.part.delta; session.next.tool.* and session.next.text.delta no longer fire. The existing streaming.ts handlers already cover the new contract, so no source change was needed; the legacy session.next.* handlers are retained as a fallback.

Renovate is capped at <=1.15.13 so moves past the validated release stay deliberate.

Scope is the action + runtime client bump. The workspace executor image stays on 1.14.41 until the gateway mention-loop tool-progress renderer is migrated for the new contract (follow-up) — a Renovate rule holds the workspace Dockerfile's OpenCode ARG at 1.14.41 so the global cap cannot bump it ahead of that cutover.

[fro-bot]

Verdict: PASS

Clean, well-scoped version bump. The OpenCode pin moves 1.14.41 → 1.15.13 consistently across DEFAULT_OPENCODE_VERSION, both @opencode-ai/sdk declarations (root + runtime), the lockfile, and the Renovate allowedVersions cap. The dist/ churn is regenerated vendor bundle output (variable renames only) and matches the source bump.

I verified the central claim in the PR description against the code: the 1.15.13 event contract (tool lifecycle + text via message.part.updated / message.part.delta) is already handled by the action harness at src/features/agent/streaming.ts:240-276, with the legacy session.next.* handlers retained as fallback (streaming.ts:162-237). No source change is genuinely required for the action — the assertion holds.

The deliberate version skew is also internally consistent: the workspace executor image (deploy/workspace.Dockerfile:39) intentionally stays on ARG OPENCODE_VERSION=1.14.41 because the gateway's tool-progress renderer (packages/gateway/src/execute/run-core.ts:259-300) still depends on session.next.tool.*, which no longer fires on 1.15.13. The gateway talks to the workspace server (port 9200), so pairing the 1.14.41 server with the session.next.* consumer is correct for now. The follow-up to migrate run-core.ts to the new contract before bumping the workspace is the right sequencing.

Blocking issues

None.

Non-blocking concerns

• Renovate will try to re-couple the workspace ARG. The customManager at .github/renovate.json5:48-56 tracks deploy/workspace.Dockerfile's ARG OPENCODE_VERSION against anomalyco/opencode under the same <=1.15.13 cap. Because the workspace ARG is deliberately held at 1.14.41 (below the cap), Renovate's next run will open a PR bumping it to 1.15.13 — silently undoing the intentional skew and breaking gateway tool-progress rendering until run-core.ts is migrated. This is reviewable (OpenCode is not in the tsdown-only automerge rule at renovate.json5:118-126), so it won't merge unattended, but it adds noise and a footgun. Consider a temporary pin/ignore for the workspace ARG until the gateway follow-up lands (e.g., a matchFileNames: ['deploy/workspace.Dockerfile'] rule holding OpenCode at 1.14.41, or enabled: false on that custom manager).
• Commit-message vs. PR-description mismatch. The commit body states it "Bumps... the workspace Dockerfile ARG," but the ARG is (correctly) left at 1.14.41 and the PR description explains the deferral. The PR description is authoritative and correct; the commit message overstates the change. Minor, no action required.

Missing tests

None required for this change. Version constants and pins are config, not behavior; the new-contract handlers in streaming.ts already exist and were validated end-to-end against an isolated 1.15.13 server per the PR description. No new code paths are introduced by this diff.

Risk assessment (LOW/MED/HIGH): LOW

• Regression likelihood: Low. The action's new-contract handlers are already present and exercised; the legacy fallback remains. Blast radius is limited to the GitHub Action runtime, which is the validated surface.
• Security exposure: None. No auth, input-handling, or permission surfaces touched.
• Blast radius: Contained — the workspace executor is deliberately untouched, so the gateway/Discord path keeps running the known-good 1.14.41 pairing. The main residual risk is operational (the Renovate re-coupling noted above), not correctness.

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/agent
Run ID	26870449445
Cache	hit
Session	ses_17397472affeF3mJ5D188hmtIb

[fro-bot]

Verdict: PASS

Re-review after the update (25b1951); my prior approval was dismissed by the push. The core bump is unchanged and still correct — OpenCode 1.14.41 → 1.15.13 applied consistently across DEFAULT_OPENCODE_VERSION, both @opencode-ai/sdk declarations (root + runtime), the lockfile, and the Renovate allowedVersions cap. The dist/ churn is regenerated vendor bundle output (variable renames) matching the source bump. The new-contract event handlers (message.part.updated / message.part.delta) already exist in the action harness (src/features/agent/streaming.ts:240-276) with the legacy session.next.* path retained as fallback, so no source change is required for the action.

The primary non-blocking concern from my previous review has been resolved. The author added a file-scoped Renovate rule (.github/renovate.json5:109-120) that holds deploy/workspace.Dockerfile's OpenCode ARG at <=1.14.41, placed after the global <=1.15.13 cap so it wins for that file:

matchPackageNames: ['anomalyco/opencode'],
matchFileNames: ['deploy/workspace.Dockerfile'],
allowedVersions: '<=1.14.41',

This is exactly the targeted fix recommended. It prevents Renovate from silently bumping the workspace executor ahead of the gateway run-core.ts contract migration (which still consumes session.next.tool.*, not fired on 1.15.13), and the comment documents the removal trigger (the gateway cutover). The deliberate version skew is now enforced in config, not just convention. Verified the workspace ARG is still 1.14.41 (deploy/workspace.Dockerfile:39).

Blocking issues

None.

Non-blocking concerns

• Commit-message vs. PR-description nuance (carryover, minor). The single commit message still frames the workspace ARG handling tersely; the PR description (line 11) is the authoritative and accurate account, now including the new hold rule. No action required.

Missing tests

None required. This is a config/version change with no new code paths. The new-contract handlers in streaming.ts already exist and were validated end-to-end against an isolated 1.15.13 server per the PR description. Renovate rule correctness is declarative config, not unit-testable in this repo.

Risk assessment (LOW/MED/HIGH): LOW

• Regression likelihood: Low. Action handlers for the new contract are present and exercised; the legacy fallback remains. Blast radius limited to the GitHub Action runtime, the validated surface.
• Security exposure: None. No auth, input-handling, or permission surfaces touched.
• Blast radius: Contained and now better fenced — the workspace executor stays on the known-good 1.14.41 pairing, and the new Renovate rule removes the operational footgun that was the main residual risk in the prior review.

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/agent
Run ID	26870821765
Cache	hit
Session	ses_17397472affeF3mJ5D188hmtIb