T3 Code stable 0.0.45 accepts an opencode provider pointed at an OpenCode 2.x server and then fails in the middle of a thread. Prompts 404, the session exits with Cannot read properties of undefined (reading 'info'), and resuming silently starts a different session. Point the same instance at OpenCode 1.x and everything works first go. This is pingdotgg/t3code#19881.
Why it happens
When serverUrl is set, the version check is skipped entirely. The only gate that runs is a minimum-version check (>= 1.14.19), and 2.0.29 sails past it because 2 is greater than 1 - there is no upper bound and no capability probe. The health check does not catch it either. GET /global/health against 2.x answers 200 text/html from the SPA fallback, so connect time looks fine.
The thread then runs against v1 paths (/session/{id}/prompt_async, /question, /permission) that 2.x does not serve. Prompts 404, sometimes with an uninterpolated {sessionID} still in the path. Session resume fails the same way, because 2.x keeps sessions in separate session_v2 tables, so the lookup misses and the driver quietly starts a fresh session instead.
The fix
PR #14239 detects OpenCode 1.x versus 2.x for external serverUrl instances too, and routes 2.x to the dedicated v2 adapter. It is merged and shipping in nightlies now, with the next stable (0.0.46) to follow.
Until that lands in stable, pin a 1.x server for that provider instance - 1.14.19 is the recommended build - or move the instance to a T3 Code nightly against OpenCode 2.0.18 or newer. The field under discussion is serverUrl, as in serverUrl: http://127.0.0.1:4096, and the lesson is the gate behind it. A minimum-version check with no upper bound treats every future major as compatible, and a health endpoint that answers 200 with HTML hides the mismatch at exactly the moment a version hint would have helped.