Repository navigation
Prompt POSTed to session HTTP endpoint during config-reload window is persisted but excluded from assembled context; assistant re-emits previous reply byte-identically #51584
Description
Description
Headless deployment (opencode serve, prompts delivered by HTTP POST to the session prompt endpoint from a local automation relay). A prompt POSTed while a configuration-reload wave was in progress was persisted to session storage (sequence number and timestamp assigned) but was not included in the context assembled for the model call. The assistant "reply" to it was a byte-identical duplicate of the reply given to the previous turn 40 minutes earlier. The caller received HTTP success with the wrong answer; nothing in the response or the log marked it as stale.
Timeline (UTC; server log + session database)
| Time | Event |
|---|---|
| 23:12:26 | Last normal turn completes (assistant reply A, seq 2241) |
| 23:12:49 | Session idle |
| 23:51:59–23:53:23 | Config-reload wave: burst of configuration normalization diagnostic WARN entries (80 log lines in this window) |
| 23:52:03.509 | Relay POSTs a new prompt to the session endpoint (logged) |
| 23:52:03.5xx | User message persisted (seq 2252); assistant message created same second (seq 2254) |
| — | seq 2254 text part: length 888, SHA-256 99d2738f39eb9edb6042936b… — identical to reply A |
Evidence
- Session database (
session_message): user row seq 2252 and assistant row seq 2254, both at 23:52:03. No other turn between 23:12:49 and 23:52:03 — the session was idle, so a concurrent running turn cannot explain a reused response. - SHA-256 of the seq 2254 text part equals the SHA-256 of the seq 2241 text part (the 23:12:26 reply): byte-identical duplicate, not a paraphrase.
- The POST timestamp falls inside the config-diagnostic burst. POSTs to the same endpoint outside reload windows, before and after, produced correct replies.
- Interpretation (the only one consistent with the above): the persisted prompt was not part of the context assembled for that model call, so the model re-answered the previous turn.
Expected: the POSTed prompt is included in the context assembled for the next model call, and the assistant answers the new prompt.
Actual: the prompt is persisted but skipped during context assembly. The assistant regenerates the previous reply byte-for-byte. The caller sees success carrying the wrong answer — a silent failure for headless/automated deployments; no error is surfaced anywhere, so callers must detect it themselves (e.g. by hashing consecutive replies).
Plugins
None configured (no plugin entries in user config, no local plugin files) — the reload wave was pure config-file normalization.
OpenCode version
v2.0.16 (npm @opencode/cli; upstream git tag v2.0.16, object sha 3a103fe0)
Steps to reproduce
Not yet reduced to a minimal script. Observed sequence:
opencode servewith a session that has at least one completed turn; let it go idle.- Trigger a config reload (rewrite the user config file).
- Inside the reload window, POST a new prompt to the session prompt endpoint.
- Observe: the user message is persisted with a sequence number; the assistant reply is identical to the previous turn's reply.
Screenshot and/or share link
None — headless server deployment; the evidence above is taken from the server log and the session database.
Operating System
Linux 7.2.5-3 x86_64 (Arch-based)
Terminal
Not applicable — headless opencode serve bound to loopback; client is curl over loopback (shell: bash)
Activity
github-actions commentedon Sep 27, 2026
Thanks for updating the issue with the Bug Report template, reproduction context, and system information. This now meets the issue guidelines.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed timeline. I tried to reproduce this on 2.0.16 with
opencode serveand a simulated model that echoes back the last user message it receives, so a prompt missing from the context would show up as a stale reply.opencode.jsonc15 times (adding unknown keys that triggerconfiguration normalization diagnostic, and switching models so I could confirm each reload was applied). Each rewrite was followed 0–80 ms later by a prompt POST.In all 46 model requests the new prompt was the last user message, and every stored assistant reply answered its own prompt. I didn't get a stale or duplicated reply.
A reply that matches the earlier one byte for byte would also fit something outside context assembly, such as a response cache at the provider or a gateway, or the relay sending the earlier prompt again. These would help narrow it down:
--log-level debug.You can reply here, or edit the issue and then leave a comment saying you've updated it.
opencodejr commentedon Oct 31, 2026
We're closing this for now because we couldn't reproduce it and haven't heard back. On 2.0.16 we sent 46 prompts over the HTTP API while the global config was being reloaded, both one rewrite at a time and during a continuous rewrite burst. Every prompt reached the model, and every stored reply answered its own prompt.
If it happens again, please comment here or open a new issue with:
--log-level debugWe'll be glad to look again. Thanks for the detailed report.