Repository navigation
v2: restore part.delete (no way to drop tool/reasoning parts) #44984
Description
Problem
V1 had DELETE /session/:sessionID/message/:messageID/part/:partID (part.delete). V2 (opencode2, beta) does not.
Protocol server.message is read-only (GET /api/session/:sessionID/message). Session writes include session.remove, compact, revert — no part or message delete.
Parts live in session_message.data JSON. Clients cannot drop tool/reasoning payloads from long sessions. The DB grows; UI-only hiding does nothing. Direct SQL against a live daemon is unsafe.
Expected
Restore a native mutation, same ownership as V1:
DELETE /api/session/:sessionID/message/:messageID/part/:partID- Update the
session_messageprojection (not a raw row delete of aparttable — that table is gone) - Emit the usual session/message events so TUI/desktop stay in sync
Batch prune of tool/reasoning parts can wait; the single-part delete is the missing primitive.
Repro
opencode20.0.0-beta-18155(d6deb62379)- Open a session with large tool/reasoning parts
- No API to delete a part.
session.removedeletes the whole session only.
Environment
- OpenCode:
0.0.0-beta-18155(branchbeta) - OS: Windows 11
Activity
opencode-agent commentedon Aug 26, 2026
Addressed by #45015. V2 now provides a native message-content mutation through
PATCH /api/session/:sessionID/message/:messageID, allowing clients to remove selected tool or reasoning parts from a completed assistant message without direct database writes or reviving the V1 part-table API. The replacement is recorded durably, projected into storage, and propagated to live clients; active, incomplete, and non-assistant messages are rejected. Closing as resolved on the v2 branch.rekram1-node commentedon Sep 8, 2026
Hey, we’re going to remove
session.messageUpdatein #48043. We added it too quickly without fully thinking through how it fits the session model—sorry for the back-and-forth.Session history is intended to be append-only. Ideally, filtering tool or reasoning content from model input should happen through a context hook rather than by editing stored history. We’re also expanding session hooks across the main agent loop, transient generation (
generate), title generation, and compaction.We realize context hooks don’t address the database-size concern you raised, since they don’t delete stored content. Would dedicated database cleanup cover your needs—for example, opt-in automatic cleanup of older sessions after a configurable N days? Are there specific cleanup primitives you’re missing, or does your workflow require selectively deleting content within sessions you’re still using? Understanding that would help us design the right solution. If there’s a clear gap or broader demand, we’re open to revisiting this with a more deliberate design.
pascalandr commentedon Sep 9, 2026
@rekram1-node Yes, we need to selectively remove tool/reasoning content from sessions we are still actively using, while preserving the conversation and its useful history.
CodeNomad 0.20.0 relies heavily on this capability, and we’re close to release. I adopted the native API added in response to this issue, so removing it without a replacement is a serious blocker for us.
CodeNomad users' workflow involves hundreds of parallel, long-lived sessions. Context hooks don’t reclaim storage, and deleting sessions after N days would discard history we still need. Those are useful features, but neither replaces selective cleanup.
I understand the concern about arbitrary history editing, but why does that require removing selective deletion too? What technical constraint makes history strictly append-only in V2, when V1 supported this use case?
We don’t need a general history editor—just a safe, supported way to prune bulky technical content without losing the session. Could you please keep this capability available until a narrower replacement exists? I’d be happy to help test it.
thdxr commentedon Sep 9, 2026
any api we include is something that we are stuck supporting forever. all clients would need to handle this case especially when it happens in real time
we didn't like how this turned out in v1
and as soon as we partially support a pattern, people will ask to keep expanding it to cover more
what you could do is use the new rpc api to directly open the sqlite db if you want and emitting your own events
ill consider adding ctx.db to plugin api but you can open it on your own for now
pascalandr commentedon Sep 9, 2026
@thdxr Thanks for clarifying. A plugin/RPC approach could work for CodeNomad without requiring a dedicated public deletion API.
If plugins are expected to own this, could you clarify the supported way to coordinate database writes with session execution and notify existing clients?
ctx.dbwould help, but we’d also need to know how to avoid stale client state or conflicts with OpenCode’s own writes.feat(pruning): restore opt-in selective deletion through native plugi…