[bug(opencode)] Resuming an opencode session never re-registers on 2.2.1 -> all writes fail

[Julpach65]

[bug(opencode)] Resuming an opencode session never re-registers on 2.2.1 -> all writes fail

Summary

On engram 2.2.1, any opencode conversation that is resumed (reopened) after its session was ended is permanently unable to write observations/prompts from that opencode process. Every attributed write aborts with:

gentle-engram could not confirm Engram session registration for <tool>

Environment

• engram 2.2.1 (latest release, 2026-09-25)
• opencode (Node) 1.18.33, Windows 11, plugin regenerated via engram setup opencode
• Write path: plugin -> serve POST /sessions (ensureSession) then observation write

Repro

1. Start opencode on a conversation (id ses_xxx). Writes work.
2. End that session with POST /sessions/{id}/end (plugin dispose/close hook or mem_session_end).
3. Resume the SAME conversation (opencode keeps a stable session id across restarts).
4. Ask the agent to save a memory. Write fails.

Root cause

• The opencode host adapter resolves the session's stable id (data.sessionID) on every attributed write and calls POST /sessions via ensureSession(sessionID, renew=true).
• For an id whose row has ended_at set, the serve replies 409 {"code":"session_already_ended"} and the session is never re-registered/re-opened. There is no reopen/restart endpoint (checked /restart, /reopen, DELETE /sessions) and engram delete session refuses sessions that have observations.
• Reads still work (MCP path is separate), which makes the failure confusing: mem_context/doctor fine, all writes blocked.
• Workaround on our side: clear ended_at directly in SQLite, then POST /sessions returns 201. Confirmed end-to-end.

Suggested fix

When a host re-registers an id that exists with ended_at set, treat it as an intentional reactivation (reopen) instead of returning 409 — or provide an explicit reopen endpoint. This is the same family as the pi --continue bug (#1376/#1387), now also reachable from the opencode host. The claude and codex adapters got a registration confirmation at resume (#1478, #1513); the opencode adapter is the remaining gap (#1485 draft).

Related: #1376, #1387, #1396, #1478, #1485, #1513.

[jorgehn98]

Independent reproduction, with a trigger that is broader than "resume after restart", and the mechanism confirmed from the database.

I hit this today without resuming anything. The trigger was a plain plugin reload (opencode reload) inside a session that was still in active use:

field	value
session	ses_f129aecf4ffejtOqs64QsA28ld
started_at	2026-09-29 14:59:43
ended_at	2026-09-29 18:31:36
runtime_lease_expires_at	2026-09-29 19:01:14

18:31:36 is exactly when the reload ran. The session kept running in OpenCode afterwards — same id, same conversation, no restart and no resume. Three consequences, all silent:

1. It cannot be re-registered. POST /sessions with that id returns {"code":"session_already_ended","error":"session has already ended","session_id":"ses_..."}. The runtime lease was still valid for another 30 minutes and made no difference.
2. Prompt capture stops. The last user_prompts row for that session is from 18:15:15. Prompts submitted after the reload were never captured.
3. MCP writes are refused, with exactly the error in your report: gentle-engram could not confirm Engram session registration for engram_mem_save.

So the trigger is not only "end the session, then resume it": any plugin reload mid-session permanently disables memory for that session, and there is no signal anywhere that it happened. I lost the second half of a long session to this before I understood why.

cleanup() → hooks.dispose() closes the sessions the plugin owns, which is reasonable on a real shutdown — but an OpenCode session survives the reload that ended it, so from here on the plugin and the server disagree about whether the session is alive, and the plugin loses every time.

Suggested direction, same as #1522: a plugin dispose is not a session end. Either leave sessions open on dispose and let the lease expire on its own, or mark them detached instead of ended, and allow re-registration to revive a session whose lease has not expired. A louder failure on the 409 would also help — right now it collapses into a generic confirmation error that points away from the real cause.

[Alan-TheGentleman]

Also reproduced on OpenCode 2.x (2.0.19) with the dual-major adapter from #1526, during the real-host checks for that PR:

• opencode run --standalone -s <id> for an existing session, or restarting opencode serve and continuing the same session: the previous process's plugin dispose ended the session, and the next capture's POST /sessions returns 409 session_already_ended.
• On V2 the automatic prompt capture from session.inbox.enqueued is then silently dropped, not just attributed tool writes: no /prompts row for any later turn. Compaction likewise skips context injection for that session (by design, no cross-session fallback).
• A session started on a long-lived server keeps capturing normally until that server process exits.

So the fix here should cover both majors; #1522 is the same root cause (it also asks to surface the 409 instead of the generic 700).

[NicoLencina]

Additional occurrence on the latest published release, so the #1564 fix does not appear to be available to users yet.

Environment

• Engram 2.2.1 (latest published release, 2026-09-25)
• OpenCode 1.18.34, Linux (x86_64)
• Integration tooling: Gentle AI 3.7.0

Observed

In an OpenCode conversation that was continued/resumed, attributed writes fail while reads keep working:

• mem_save fails with:

  gentle-engram could not confirm Engram session registration for engram_mem_save; verify that the Engram server is available and retry.
  

• mem_session_summary fails the same way. Read paths succeed (mem_current_project, mem_context, mem_search, mem_get_observation), and updating an existing observation with mem_update also succeeds. Only the attributed writes are rejected.
• A separate conversation saved a new observation and read it back successfully.
• Local diagnostics looked healthy: no ambiguity and no SQLite lock contention reported.

Context and ask

The symptom appears equivalent to this report, but the in-process disposed/local-readiness causal flags were not externally observable, so I am not asserting the mechanism for this occurrence. A full restart has not been performed or verified.

PR #1564 is merged, but it landed after the last published release (v2.2.1, 2026-09-25). Which published release contains or will contain that fix? If this is already handled, no new issue is needed.