v2: selective session-content deletion is missing again after #48043 #48090

Activity

1. github-actions

   assigned

   kitlangton

   on Sep 9, 2026
2. github-actions commented on Sep 9, 2026

   

   github-actionsBot

   on Sep 9, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue doesn't fully meet our contributing guidelines.

   What needs to be fixed:

   • The issue does not use one of the three required templates: Bug Report, Feature Request (title must start with [FEATURE]:), or Question. Please resubmit using the appropriate template so required fields are captured consistently.

   Please edit this issue to address the above within 2 hours, or it will be automatically closed.

   ---

   This issue might be a duplicate of existing issues. Please check:

   • v2: restore part.delete (no way to drop tool/reasoning parts) #44984: v2: restore part.delete (no way to drop tool/reasoning parts) — the direct predecessor to this report, closed as resolved after session.messageUpdate was added, which has now been removed per your description.

   If you believe this was flagged incorrectly, please let a maintainer know.
3. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Sep 9, 2026
4. opencode-agent

   added

   2.0

   on Sep 9, 2026
5. github-actions

   removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Sep 9, 2026
6. github-actions commented on Sep 9, 2026

   

   github-actionsBot

   on Sep 9, 2026 – with GitHub Actions

   Contributor

   More actions

   Thank you for updating the issue! It now follows the Bug Report template with clear description, reproduction steps, and system information. The compliance flag has been removed.
7. opencode-agent commented on Sep 9, 2026

   

   opencode-agentBot

   on Sep 9, 2026 – with OpenCode Agent

   Contributor

   More actions

   Could you give us one concrete end-to-end example of how CodeNomad uses this? We want to separate a few potentially different needs:

   • Is the primary problem persistent database/disk growth? If so, roughly how large or fast-growing are these sessions, and do you specifically need the operation to reclaim filesystem space?
   • Is the primary problem model-context capacity? If hooks already omit these parts from model input, what remains unsolved—such as repeatedly breaking prompt-cache prefixes or the cost/complexity of filtering?
   • Is the desired behavior automatic pruning of old/large tool outputs, manual deletion of individually selected parts, or both? Which part types do you remove in practice?
   • Must the deletion be reflected in stored history and every connected client, or would a persisted “exclude from future model context” marker satisfy the workflow?

   A concrete before/after session example, plus approximate session count/size, would help us understand the invariant and whether this should be a constrained pruning operation rather than general message mutation.
8. opencode-agent commented on Sep 9, 2026

   

   opencode-agentBot

   on Sep 9, 2026 – with OpenCode Agent

   Contributor

   More actions

   If you can describe the exact flow you want and how CodeNomad would use it step by step, that would be great.

   👍React with 👍1Reacted by Pascal André
9. pascalandr commented on Sep 9, 2026

   

   pascalandr

   on Sep 9, 2026

   Author

   More actions

   A typical workflow is a long-running coding session with lots of file reads, searches, build logs, and reasoning. Once a step is finished, I want to keep the discussion and conclusions but remove technical content I no longer need, then continue the same session.
   CodeNomad lets users remove one tool/reasoning block, the blocks in a message, or all of them across a session. It previously fetched the completed message, filtered the selected parts, and saved it through session.messageUpdate. This is manual cleanup, not arbitrary rewriting or automatic pruning.
   There are two needs: free up model context and clean the stored history so clients no longer have to load those large payloads. The deletion should be reflected across connected clients.
   A persisted exclusion marker could help with context, but we’d still need actual cleanup of the stored content. Reclaiming disk space can happen later through a separate maintenance operation—not on every click.
   Codenomad's users work with hundreds of parallel, long-lived sessions; A narrow pruning API for completed tool/reasoning blocks would cover this well.
10. pascalandr commented on Sep 9, 2026

    

    pascalandr

    on Sep 9, 2026

    Author

    More actions

    I’ve now measured the storage impact on an offline backup: 23.12 GB initially, 18.67 GB with VACUUM alone, and 4.92 GB after removing tool/reasoning content from both V2 history and retained V1 tables, then vacuuming.
11. pascalandr

    added a commit that references this issue on Sep 10, 2026

    feat(pruning): restore opt-in selective deletion through native plugi…

    ...

    ea37f97
12. DDDMUC commented on Sep 30, 2026

    

    DDDMUC

    on Sep 30, 2026

    More actions

    Adding a data point from plugin-side experiments (OpenCode 1.18.33, plus the current dev sources):

    1. The experimental.chat.messages.transform hook is already sufficient for removing complete messages from model input — not just tool/reasoning parts. It is triggered in packages/opencode/src/session/prompt.ts:1255 (step 1) and packages/opencode/src/session/compaction.ts:379, both immediately before the message list is converted for the provider, and mutating output.messages drops entries from the request as well as from the compaction summary. So the “model-context capacity” half of this issue is solvable today by a plugin, with no storage mutation, and it works for whole user/assistant messages, not only technical parts.
    2. What a plugin cannot do (verified): hide the row in the transcript. The TUI plugin surface has no message-content slot (TuiHostSlotMap in @opencode-ai/plugin exposes only app/home/prompt/sidebar slots), and there is no message delete endpoint (only GET /session/{id}/message/{messageID}; the range-based revert is not a substitute). The resulting UX is “the model forgets, the screen keeps the message”, which matches the storage half of this issue and the measurement above.
    3. Small API gap for plugin authors: the hook input is {} — in dev too (packages/plugin/src/index.ts:282, prompt.ts:1255, compaction.ts:379). Passing sessionID (and optionally model) would let a plugin scope its filter per session instead of carrying a global message-id set. Cheap, additive, no behavior change.

    To be clear, this is not a request to bring back the removed mutation API (#48043) — it is an attempt to separate what is already solved (model context, via hooks) from what is still open (stored history / disk, e.g. pruning + VACUUM as measured in this thread).
13. opencodejr commented on Oct 28, 2026

    

    opencodejrBot

    on Oct 28, 2026

    Contributor

    More actions

    Thanks for the detailed follow-up, @pascalandr, and for the context on how CodeNomad uses this.

    You're asking for a supported, limited way to remove selected completed tool/reasoning content from sessions that are still in use, without deleting the sessions. That would free model context, reduce stored history, and include a supported way to reclaim unused database space. You're also asking for this to happen inside OpenCode rather than through clients writing to its tables directly.

    session.messageUpdate was removed on purpose in #48043, so I'm treating this as a feature request for a narrower replacement rather than a regression. The reasons maintainers gave in #44984 were that session history is meant to be append-only and that any public API has to be supported long-term by every client. Your proposal of restrictions rather than removal (only completed tool/reasoning parts, only idle sessions, events sent to clients) and the separate storage-reclamation need are clear, and maintainers will consider them. I can't promise an outcome.

    Related:

    • v2: restore part.delete (no way to drop tool/reasoning parts) #44984: the original request for v2 part deletion, including the maintainer discussion about the RPC/plugin route
    • fix(session): support assistant message content updates #45015: the PATCH /api/session/:sessionID/message/:messageID API that addressed it
    • refactor(session): remove message content mutation API #48043: the PR that removed it, which notes that context hooks don't reclaim storage