Repository navigation
[FEATURE]: Read-only historical execution changesets for V2 plugins #52870
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
Updated request: read-only historical changesets for V2 plugin consumers, rather than awaited plugin capture callbacks. Related discussions include #23503, #35540 and #9272; I am happy to consolidate if maintainers prefer.
Snapshot/review plugins need to inspect a completed execution after the next execution has already started. Reading the current filesystem can mix their changes. V2 already stores step snapshot references, but the public session diff does not expose an exact execution closure with verified snapshot boundaries and capture/rendering coverage.
Could plugins retrieve a historical changeset by an exact execution closure, with:
- the corresponding initial/final snapshot references, or an explicit boundary-unavailable result;
- frozen scope/coverage and typed omissions or failures, such as ignored relevant paths, capture limits, binary content and patch truncation;
- rendering independent of the current worktree, ignore rules, attributes and Git presentation configuration?
An empty patch should distinguish a complete empty delta from unavailable or incomplete evidence. Initial support could be Git text only, with other cases explicitly unavailable. This would not certify exclusive authorship, task fulfillment or settlement of detached writers. No fallback to the current worktree, prompt injection or loop continuation is requested.
A local offline experiment with the real execution coordinator, Bus and native snapshots, but a scripted runner, preserved E1's historical delta while E2 changed the same file; closure association survived database reopening and replay. Coverage remained UNKNOWN. Establishing execution boundaries required two additional host captures in that experiment, so it does not demonstrate zero latency or that exposing Snapshot.diff alone is sufficient.
I am requesting design review before a production implementation. Would a closure-addressed changeset fit V2, and which parts of boundary identity, coverage and retention should belong in the public contract? Complete delivery-history access remains a separate requirement for my consumer.
Activity
github-actions commentedon Oct 2, 2026
This issue might be a duplicate of existing issues. Please check:
session.before.idlehook for asynchronous plugin work around subagent completion, overlapping with the callback timing.pablozr commentedon Oct 3, 2026
Thanks for flagging these. I checked all three, including the diff of #9272. There is real overlap: #35540 asks for an awaited final flush, #23503 shares the snapshot/review use case, and #9272 adds awaited work before idle plus a resumePrompt continuation path.
The distinction here is paired observation boundaries in V2: a baseline before the first drain and a final observation after cleanup, awaited before terminal publication and a same-session successor. The callbacks would have a total phase deadline, reject late results, and neither resume the loop nor inject prompts or change the runner outcome. On timeout, pending I/O may continue; its result must not become accepted evidence.
A completion notification alone does not establish that ordering. I am happy to consolidate this into an existing discussion if maintainers prefer, rather than introduce a competing hook. Which direction fits the V2 plugin API best?
[-][FEATURE]: Bounded plugin hooks at V2 session execution boundaries[/-][+][FEATURE]: Read-only historical execution changesets for V2 plugins[/+]pablozr commentedon Oct 3, 2026
Sorry for the change in direction and the earlier callback-focused proposal. After inspecting and testing V2's native snapshots, I think a read-only historical changeset contract is a better starting point than asking plugins to duplicate capture through awaited hooks.
I updated the title and description rather than opening another overlapping issue. The revised request is for exact execution-closure correlation and explicit capture/rendering coverage, not merely exposing the current session diff. Our experiment still has UNKNOWN coverage and used a scripted runner; it is not a production patch, and its extra host captures do not imply zero latency.
The earlier comment describes the superseded approach. Please let me know if this belongs in an existing discussion or should be split. I would appreciate design feedback before implementing the definitive interface.