Repository navigation
[FEATURE]: Awaited plugin hook before session revert commit #59079
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'd like an awaited plugin hook that runs before a session revert is committed.
Problem. I'm writing a plugin that keeps a copy of reverted messages, so a user can go back to the old branch later. In v2.1.4 a plugin can't do that reliably:
- On commit, the revert projector deletes the boundary message and everything after it before event subscribers run (projector.ts#L781-L816).
- No plugin hook runs before the explicit commit (session.ts#L350-L353). The prompt hook runs before the implicit commit, but the app and TUI commit explicitly first.
- Listening to
session.revert.stagedand reading the messages right away works sometimes, but it races the commit. - Durable event payloads would also work, but the CLI server doesn't persist them by default (CLI server cannot enable durable event persistence #42839).
Proposal. Add an awaited hook, for example session.revert.beforeCommit, that receives the session ID and the revert boundary. It runs in the commit path before the projector deletes anything, while the messages are still readable. If the hook fails, keep the messages, or at least log the failure.
Related: #42839 (durable events on the CLI server), #51599 (plugins can call revert, but there is still no hook before commit).
If the design sounds OK, I'm happy to send a small PR with tests.
Activity
opencode-agent commentedon Oct 25, 2026
Thanks for the detailed write-up! You're asking for an awaited plugin hook, for example
session.revert.beforeCommit, that runs before a staged revert is committed. That way a plugin can still read and save the messages the commit is about to delete.The current code matches what you describe:
Session.revert.commitgoes straight toSessionRevert.commitwithout calling any plugin hook first, and none of the existing plugin hooks cover revert. So this can't be built reliably as a plugin today, and it would need an addition to the plugin API. Maintainers will consider it, including the design you propose (session ID and revert boundary as input, and keeping the messages or logging if the hook fails). It's probably best to wait for their view on the design before starting the PR.Related: