Resuming an old session exits silently (no API call, no error) — even with a valid --model override; stale recorded model also breaks resume

[irlovanwon]

Description

Old sessions can no longer be continued after restarting opencode. Two layers of failure:

1. Stale model reference: Sessions last used with a model that the provider has since removed (zai-coding-plan/glm-5.1) fail to resume with ProviderModelNotFoundError (only visible in logs).
2. Silent exit even with a valid model override: Even when passing --model zai-coding-plan/glm-5.2, resuming an old session exits the session loop immediately (~20ms, step=0 → exiting loop) with no API call, no error output, and exit code 0. The user message is persisted, but no assistant reply is ever produced.

Freshly-created sessions resume fine, so this is specific to replaying sessions created by an older version.

Environment

• opencode: 1.17.13 (Linux x64)
• Session originally created with: 1.16.2
• Provider: zai-coding-plan (glm-5.1 recorded in session; glm-5.1 since removed from provider's model list — glm-4.7 / glm-5-turbo / glm-5.2 remain)

Reproduction

$ opencode run --session <old-session-id> --model zai-coding-plan/glm-5.2 "Reply with exactly: OK" --format json
# (no output at all, exit code 0)

$ opencode run --session <old-session-id> --model zai-coding-plan/glm-5.2 "Reply with exactly: OK" --print-logs --log-level DEBUG 2>&1 | tail -3
timestamp=2026-08-15T14:13:45.216Z level=INFO run=2b186860 message=loop session.id=ses_161a26406ffe... step=0
timestamp=2026-08-15T14:13:45.233Z level=INFO run=2b186860 message="exiting loop" session.id=ses_161a26406ffe...
timestamp=2026-08-15T14:13:45.239Z level=INFO run=2b186860 message="disposing instance" directory=/home/irlovan/AOC/Test

Without the model override, the log additionally shows:

level=ERROR message="share subscriber failed" type=message.updated cause="Cause([Fail(ProviderModelNotFoundError: Model not found: zai-coding-plan/glm-5.1. Did you mean: glm-4.7, glm-5-turbo, glm-5.2?)])"

What I verified while debugging

• Resuming a brand-new session (created and resumed with the same 1.17.13 binary) works fine → not an environment/auth issue.
• I patched all 412 stale "modelID":"glm-5.1" references in message.data to glm-5.2 and updated session.model in the DB — resume still exits silently. So the stale model is not the only cause; old-session replay itself is broken.
• Session data is structurally intact: no orphan parts, no malformed JSON, all tool parts have valid states, time_compacting is NULL.
• OPENCODE_DISABLE_AUTOCOMPACT=1 makes no difference.
• --fork works and preserves full conversation context.

Expected behavior

• Resume should either work, or surface the error (e.g. "model no longer available — pick another") instead of exiting silently with code 0.
• A --model override on run/tui should take precedence over the model recorded in old messages.

Workaround

Fork the session (copies history into a new session that resumes fine):

$ opencode --session <old-session-id> --fork

Related

• Subagent sessions created with model=undefined causing ProviderModelNotFoundError #33043 / ProviderModelNotFoundError: subagents fail on tool-using tasks across all categories #31141 mention ProviderModelNotFoundError for subagents with model=undefined — possibly the same class of stale/missing model resolution, but this report is about top-level session resume.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Subagent sessions created with model=undefined causing ProviderModelNotFoundError #33043: Subagent sessions with model=undefined causing ProviderModelNotFoundError — same error class, possibly the same model resolution path
• stale synthetic continuation rows can overwrite the session model #33044: Stale synthetic continuation rows overwriting session model — directly covers stale recorded model breaking session resume
• Run loop can never exit when message ids are not time-sortable (imported sessions loop until the provider 400s) #38791: Run loop never exits with old/imported sessions (imported sessions loop until provider 400s) — same symptom of exiting loop at step=0 with no API call for sessions created by older versions