[Bug] Local lifecycle closes surface as failed tool cards

[Astro-Han]

What happened?

Active assistant runs can be interrupted by local lifecycle actions and then surface as failed tool cards. This looks like a tool failure even though the tool did not fail and, in the captured cases, did not actually start running.

Two local session exports show the same broad failure class with different lifecycle triggers:

• pawwork-session-silent-eagle-2026-05-25-06-42-28-tool-execution-aborted.json

  • App version: 0.0.0-prod-202605201754
  • Classification: local_instance_reload
  • Lifecycle: instance_reload
  • Tool state: bash input was fully materialized, tool_call_seen: true, tool_execution_started: false
  • UI text: Tool execution aborted

• pawwork-session-calm-river-2026-05-25-06-59-38-Tool call generation interrupted before the tool ran..json

  • App version: 0.0.0-prod-202605241640
  • Classification: local_instance_dispose
  • Lifecycle: instance_dispose_all
  • Origin: settings.provider.connect -> POST /global/dispose -> Instance.disposeAll()
  • Tool state: tool input generation started but did not complete, tool_call_seen: false, tool_execution_started: false
  • UI text: Tool call generation interrupted before the tool ran.

This is distinct from a provider/network stream disconnect. The captured failing traces have provider progress, no watchdog timeout, no provider error event, no tool error result, and no tool execution start.

Which area seems affected?

Model harness, prompts, tools, or session mechanics

How much does this affect you?

Breaks an important workflow

Steps to reproduce

1. Start an assistant run that is preparing or about to run a tool.
2. Trigger a local lifecycle action while the run is active. Captured examples:
   • Reload the active project instance.
   • Connect a provider from settings, which calls global.dispose() with client action settings.provider.connect.
3. Return to the active session timeline.
4. See the active assistant turn marked interrupted with a failed tool card.

What did you expect to happen?

Local lifecycle closes should be presented as local app/session interruptions, not as tool failures. If a tool never started, the UI should make that clear and the incident classification should guide the user toward the local lifecycle trigger.

PawWork version

Observed on:

• 0.0.0-prod-202605201754
• 0.0.0-prod-202605241640

OS version

Observed on macOS / Darwin:

• 25.4.0
• 25.5.0

Can you reproduce it again?

Sometimes

Diagnostics

Relevant code paths from the local investigation:

• packages/opencode/src/session/processor.ts maps interrupted tool parts to Tool execution aborted, Tool call was prepared, but the tool did not run before the interruption., or Tool call generation interrupted before the tool ran. based on interruption phase.
• packages/opencode/src/session/run-observability/recorder.ts classifies lifecycle scope closes as local_instance_reload or local_instance_dispose.
• packages/app/src/components/dialog-connect-provider.tsx calls global.dispose() with settings.provider.connect.
• packages/opencode/src/server/instance/global.ts handles /global/dispose by calling Instance.disposeAll().

The key product problem is not whether the run was correctly aborted internally. It is that local lifecycle aborts currently surface to users as failed tool cards, making them look like command/tool failures or generic connection failures.

[Astro-Han]

Design note: keep active runs alive across local lifecycle refreshes

This comment reframes the issue goal. The user-visible failed tool card is a symptom. The root product bug is that a background local lifecycle action can terminate an active assistant run even though the user did not cancel that run.

Invariant

Once a user run starts, its execution lifetime must be owned by the run/session, not by the project instance cache.

Local maintenance actions may refresh project state, provider state, config, watchers, LSP, file caches, or plugin state. They must not interrupt an active run unless one of these is true:

• the user explicitly cancels the run;
• the user explicitly confirms an action that says it will interrupt the run;
• the process is shutting down and no continuation is possible.

What we know

The captured incidents are local lifecycle closes, not provider/network stream failures.

• silent-eagle: local_instance_reload, tool call was materialized, tool_execution_started: false, UI showed Tool execution aborted.
• calm-river: settings.provider.connect -> POST /global/dispose -> Instance.disposeAll(), tool input generation had started but did not complete, tool_execution_started: false, UI showed Tool call generation interrupted before the tool ran.

Local focused repros confirm the current ownership chain:

• bun test test/session/run-state.test.ts -t "fans out one disposeAll lifecycle action to multiple in-flight runs"
• bun test test/session/run-state.test.ts -t "annotates global dispose interrupts with request origin"
• Related config-origin tests also show that config update / invalidate paths can terminate active runs.

The concrete chain today is:

1. Instance.disposeAll() / Instance.reload() calls instance disposers.
2. InstanceState.make(...) registers a disposer that invalidates the directory-scoped cache.
3. SessionRunState is itself stored in InstanceState.
4. Invalidating that cache closes SessionRunState's scope.
5. The SessionRunState finalizer iterates active runners and calls runner.cancelWith(...).
6. Runner interrupts the active run fiber.

Relevant files:

• packages/opencode/src/effect/instance-state.ts
• packages/opencode/src/session/run-state.ts
• packages/opencode/src/effect/runner.ts
• packages/opencode/src/project/instance-store.ts
• packages/app/src/components/dialog-connect-provider.tsx
• packages/opencode/src/server/instance/global.ts

Upstream comparison

Upstream had a related bug: anomalyco/opencode#24859, fixed by anomalyco/opencode#25114.

That upstream fix prevents one bad trigger: opening settings caused a no-op config write, which caused Config.updateGlobal -> invalidate() -> disposeAll() -> active response interruption. Their fix was:

• client-side: do not write when the selected shell value is unchanged;
• server-side: only invalidate global config when serialized config bytes actually changed.

That does not solve this issue's deeper invariant. Current upstream still keeps SessionRunState under InstanceState, still disposes instance state on lifecycle close, and still calls global.dispose() after provider connect. So #25114 is useful precedent for reducing accidental triggers, but it is not a complete fix for "lifecycle close must not own active run lifetime."

Option A: active-run guard around lifecycle close

Before dispose, disposeAll, or reload closes an instance, check whether the affected directory has active runs. If it does, either reject the lifecycle action or defer it until the run idles.

Expected behavior:

• Connecting a provider or refreshing config while a run is active no longer kills the run.
• The lifecycle action is either delayed until idle or returns a clear "busy" result to the caller.

Likely implementation boundary:

• Add a small read API to SessionRunState or a lifecycle coordinator, such as hasActiveRuns(directory) / whenIdle(directory).
• Teach InstanceStore.disposeContext, reload, and disposeAll to consult it before running disposers.
• Update provider connect / config callers to handle deferred or busy lifecycle results.

Pros:

• Smallest safe production change.
• Directly blocks the observed failure chain.
• Keeps the current InstanceState architecture mostly intact.

Cons:

• It is a guardrail, not a clean ownership model.
• Every lifecycle close path must go through the guarded seam.
• Deferred lifecycle behavior needs careful UI/server semantics.

Option B: move active run ownership out of InstanceState

Make SessionRunState no longer depend on the disposable instance scope. Active runs get an independent session/run scope. Instance lifecycle refreshes can invalidate config, provider, watcher, LSP, file, plugin, and project caches, but cannot close active run fibers.

Expected behavior:

• Active runs continue across provider connect, config refresh, and instance reload.
• Only explicit user cancellation or process shutdown interrupts the run.

Likely implementation boundary:

• Replace SessionRunState's InstanceState.make(...) storage with a process/workspace-level store keyed by directory + session id, or an equivalent long-lived service.
• Keep explicit SessionRunState.cancel(sessionID) as the cancellation path.
• Decide how a running turn snapshots its provider/config/project context so mid-run refreshes do not mutate execution underneath it.

Pros:

• Matches the invariant cleanly.
• Fixes the whole class rather than each trigger.
• Makes future lifecycle cleanup less risky.

Cons:

• Deeper change with broader blast radius.
• Requires clear rules for config/provider changes during an active run.
• Needs more regression coverage across prompt, shell, subagent/background jobs, and session status.

Recommendation

Use Option A as the immediate fix for #898, but design it so it does not make Option B harder.

Concretely:

1. Add a failing regression test that proves global.dispose / provider-connect style disposal cannot interrupt an active run.
2. Add the smallest central guard at the lifecycle close seam, not at one UI caller.
3. Preserve existing explicit cancellation behavior.
4. Record Option B as follow-up architecture work if the guard reveals too many lifecycle callers or awkward deferred semantics.

Why not only port upstream #25114?

PawWork already has the no-op config gate. The current repro is not a no-op settings write. It includes real lifecycle actions like provider connect and instance reload. Porting #25114 alone would reduce one accidental trigger but would leave the #898 failure chain intact.

Acceptance criteria

• settings.provider.connect / global.dispose while an assistant run is active does not interrupt that run.
• instance_reload while an assistant run is active does not interrupt that run without an explicit user-approved interruption path.
• Existing user cancel still cancels the active run.
• Existing cleanup after app shutdown or test teardown still disposes resources.
• Session status returns to idle after the run naturally completes.
• Regression tests cover at least one disposeAll path and one reload or config invalidation path.

Test plan

Focused first:

• Add or update packages/opencode/test/session/run-state.test.ts to encode the new invariant instead of the current "disposeAll fans out interrupt" expectation.
• Add route-level coverage for POST /global/dispose with an active run.
• Add reload/config invalidation coverage if the chosen seam claims to cover those paths.

Then run:

• bun test test/session/run-state.test.ts from packages/opencode.
• Any changed route/config tests from packages/opencode.
• bun run typecheck for the touched package(s).

If UI behavior changes for provider connect, add a small app test or manual Electron route check, because the actual user path is in settings/provider connect.

Open questions for review

1. Should lifecycle actions while active runs exist be rejected, queued until idle, or allowed only after an explicit confirmation?
2. Should the guard live in InstanceStore, SessionRunState, or a new lifecycle coordinator service?
3. Does an active run need to hold a snapshot of provider/config/project context, or is it enough to delay lifecycle refresh until idle?
4. Are background jobs/subagents tied to a session part of the same active-run protection boundary?

[Astro-Han]

Review follow-up: narrow Option A before implementation

I checked the review items against the current code before updating the design.

Verified points

• Provider connect currently calls await actionClient.global.dispose(), then closes the dialog and shows the connected toast. Provider disconnect follows the same pattern before showing its success toast.
• POST /global/dispose currently returns only boolean, so a guarded close cannot be hidden behind the existing API without risking false success or false failure in the UI.
• InstanceStore.disposeAll() builds one lifecycle action over every loaded entry, and the store finalizer also calls disposeAll(). The guard therefore needs both global affected-directory scope and a force/teardown path.
• The current run-state tests are useful repros because they prove disposeAll, global.dispose, and config invalidation can interrupt active runs today. They should be inverted into regression tests once the behavior is fixed.

Short-term contract for Option A

Option A should use deferred maintenance, not an ambiguous mix of reject / defer / confirmation.

Introduce a central lifecycle close coordinator, name tentative, with an explicit close mode:

• maintenance: provider connect/disconnect, config refresh/invalidate, and instance reload. If any affected directory has active runs, return an explicit deferred result and run the close after all affected directories become idle.
• user_confirmed_interrupt: allowed to close active runs only after the UI clearly asks the user to confirm interruption.
• shutdown / test_teardown: force cleanup and do not wait for active runs.
• Explicit user cancel remains owned by the session/run cancellation path, not by maintenance lifecycle close.

The maintenance result should be structured, not boolean, for example completed vs deferred with affected directories and a lifecycle action id. The server should also emit a deferred/completed lifecycle event so callers and UI can stay consistent.

Why deferred maintenance is the right short-term behavior:

• Provider auth may already have succeeded before global.dispose() runs. Returning a normal request failure at that point would be misleading because the provider can be connected while the refresh failed.
• The real product intent is not "interrupt the current run"; it is "refresh local/provider state for the next interaction."
• The UI can say the provider change succeeded and the refresh will apply after the current run finishes, instead of pretending the refresh already happened.

Guard scope

• disposeAll must pass all affected loaded directories to the coordinator. It cannot check only the current directory.
• disposeContext and reload can pass a one-directory affected set.
• Callers should not directly stitch together raw hasActiveRuns checks. They should request a lifecycle close with a mode and consume the structured result. This keeps the policy centralized.

Option B prerequisite

Option B remains the cleaner final ownership model, but it needs context snapshot rules before implementation:

• A running turn keeps the provider/config/project context captured at turn start.
• Maintenance refreshes affect the next turn, not the current one.
• Explicit cancel and shutdown still interrupt the current run.

Without that rule, moving active run ownership out of InstanceState could trade "run gets interrupted" for "run keeps going while its provider/config context changes underneath it."

Updated acceptance and verification

• Provider connect/disconnect during an active run returns an explicit deferred lifecycle result. The UI does not show a false failure and does not claim the refresh has completed immediately.
• The active run completes naturally and the transcript does not render Tool execution aborted or Tool call generation interrupted before the tool ran. as a failed tool card.
• After all affected directories become idle, the deferred maintenance close runs and emits the normal completed lifecycle event.
• disposeAll protects active runs across all affected directories, including the case where directory A has an active run while directory B is also loaded.
• Shutdown and test teardown still force cleanup without hanging.
• Existing explicit user cancel still cancels immediately.
• Keep the upstream #25114-style no-op write gate. It is necessary trigger reduction, but insufficient for this lifecycle ownership invariant.