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

[pascalandr]

Description

This follows up on #44984, which remains closed even though its replacement API has now been removed.

CodeNomad 0.20.0 adopted that API. We still need a supported way to remove selected tool/reasoning content from ongoing sessions without deleting the conversations themselves.

Expected behavior: A native, constrained operation to remove selected technical content while preserving session identity, useful history, and consistency across clients.

There are two needs: freeing model-context capacity and reducing retained history/storage, including a supported way to reclaim unused database space.

Actual behavior:

• V1 supported selective part deletion.
• v2: restore part.delete (no way to drop tool/reasoning parts) #44984 requested its V2 equivalent.
• fix(session): support assistant message content updates #45015 supplied session.messageUpdate; the issue was closed as resolved.
• refactor(session): remove message content mutation API #48043 removed it without an equivalent replacement.

Context hooks can filter model input, but do not clean stored history. Deleting whole sessions after N days is not a substitute: our workflows involve hundreds of parallel, long-lived sessions whose meaningful history must remain available.

OpenCode owns the database schema, migrations, session execution, and synchronization. Safe mutation of that storage belongs in OpenCodeÔÇönot in downstream clients writing directly to its tables.

If arbitrary message replacement is too broad, please provide a narrower prune/redact operation. What concrete invariant prevents selective deletion of completed technical content, and why can that concern not be addressed with restrictions rather than removal?

Could you restore the capability temporarily, or reopen #44984 and track a replacement before treating the V1 use case as resolved? We are happy to help validate it.

OpenCode version

First affected published beta: 0.0.0-beta-19365 (@opencode/cli, published 2026-09-09).

Steps to reproduce

1. Open an existing session containing completed tool/reasoning blocks.
2. Attempt to remove selected blocks through session.messageUpdate.
3. The endpoint and generated client method are gone, with no equivalent selective-deletion operation.

Screenshot and/or share link

• Original report: v2: restore part.delete (no way to drop tool/reasoning parts) #44984
• Replacement API: fix(session): support assistant message content updates #45015
• Removal: refactor(session): remove message content mutation API #48043

Operating System

Windows 11.

Terminal

CodeNomad 0.20.0 development; diagnostic commands run in PowerShell 7.

[github-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.

[github-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.

[opencode-agent]

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.

[opencode-agent]

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

[pascalandr]

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.

[pascalandr]

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.