Repository navigation
[FEATURE]: Expose durable execution continuity to server plugins #61884
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
I'm using a server plugin that persists inference accounting and blocks unsafe automatic continuation. After an OpenCode restart, it cannot distinguish a session that previously finished safely from one interrupted during execution.
A concrete example is a completed session receiving a PR notification days later. The notification should be able to resume already-authorized work, but the plugin currently has to refuse it because the previous process's authorization cannot be verified.
In OpenCode 2.2.5, experimental.idle helps, but runs before execution settles. It can still be interrupted or followed by more input in the same execution. The public session timestamps and model.request payload don't expose a durable execution identity or continuity binding.
Could the plugin API expose enough host-owned execution lineage to:
- Correlate a plugin checkpoint with an execution that successfully finished idle.
- Detect intervening execution, interruption or deletion that invalidates that checkpoint.
- Document when exclusive ownership is guaranteed, including managed versus standalone servers.
- Return an explicit unknown state when continuity cannot be established.
OpenCode already maintains durable execution claims for restart recovery. I'd prefer to reuse that authority rather than introduce a separate ownership mechanism in the plugin.
The plugin would preserve its existing episode, counters and replay history. Genuine pauses and explicit stops would remain blocking. Historical records without sufficient proof would still require fresh user input.
The important validation cases would be a crash while already idle, a crash between the idle hook and terminal commit, failed checkpoint invalidation, and a stop racing with the handoff.
Is there an existing supported contract for this, or would a small execution-continuity addition be welcome?
Activity
opencodejr commentedon Nov 5, 2026
Thanks for the detailed write-up, @mv2sa!
You're asking for the plugin API to expose execution continuity that OpenCode itself tracks. The goal is to tie a plugin checkpoint to an execution that has fully finished, notice when a later execution, an interruption or a deletion invalidates it, and get an explicit "unknown" state when continuity can't be proven.
To answer your question: as far as I can tell, there's no supported contract for this today.
experimental.idleruns before the session actually goes idle, and input the hook admits continues the same execution. The durable execution claims inSessionExecutionare internal, so plugins can't see an execution ID, the claim state, or the moment an execution is finally committed. So this would need a small addition to the plugin API. Two possible shapes are a stable execution ID plus a notification after the execution settles, or a query that returns the last settled execution and acontinuous | broken | unknownstate. Maintainers will consider it.These issues are related, but none of them covers this request:
experimental.stoppinghook (veto before an execution completes)session.idlevssession.execution.*completion eventsjwitmann commentedon Nov 5, 2026
Following this as the author of opencode-dev-framework — my gate verdict and idle dedup live in memory, so after a restart I can't tell whether a session finished cleanly or was interrupted halfway through. A stable execution ID with a continuous/broken/unknown state is exactly what I'd build durable receipts on.