TUI: queued slash command interrupted by auto-compaction is re-submitted after every later compaction

[benjaminbelaga]

Description

When a slash command sits in the TUI follow-up queue and its submission gets interrupted by an auto-compaction, the TUI does not drop it after delivering it. It re-submits the same command after every later compaction in that session, for hours, until the TUI is restarted.

Server log for one session (opencode.log, filtered on that session.id). Everything stays on the same run= id for more than three hours:

13:20:26 run=31f51ac0 agent=compaction
13:20:35 run=31f51ac0 message=command command=autoplan
13:59:27 run=31f51ac0 agent=compaction
13:59:29 run=31f51ac0 message=command command=autopilot
15:44:37 run=31f51ac0 agent=compaction
15:44:42 run=31f51ac0 message=command command=autoplan
15:44:46 run=31f51ac0 message=command command=autopilot
16:40:36 run=31f51ac0 agent=compaction
16:41:48 run=31f51ac0 message=command command=autoplan

Nobody typed those commands after the first time. Each re-submission restarts the whole command workflow.

Observations:

• Timing. The re-send usually lands a few seconds after the compaction, sometimes at the next idle.
• Frozen text. The re-sent text is the text that was queued originally. I edited the command's markdown file on disk, and the re-sends kept carrying the old body.
• Plugins not involved. Restarting only a plugin changes nothing. Only quitting the TUI and resuming the session (opencode -s <id>) stops it.
• Scale. Across ~20 long-running sessions on one machine I counted 115 such re-submissions in 24 h.

Expected: a queued command is delivered once after the compaction, or dropped. It is never replayed on later compactions.

Possibly related, all closed: #1476, #20529, #13217. #32157 discusses compaction-aware queue semantics.

Plugins

Local plugins only, none touch the prompt queue: cmux-feed, cmux-session, command-dedup, domain-router, mission-continuity, provider-fallback, safety-bridge, session-identity, session-tracker. command-dedup now only annotates the duplicate text; it can't clear the TUI queue.

OpenCode version

1.18.32

Steps to reproduce

1. Use a session near the context limit, so auto-compaction triggers on the next turn.
2. While the agent is busy, type a slash command (for example a custom /mycommand). It goes to the follow-up queue.
3. Let auto-compaction run, and keep working in the session.
4. Watch the server log. message=command command=mycommand reappears after each later compaction of that session.

I have not reduced this to a clean-config repro. The steps above are what the logs show on my setup.

Operating System

macOS 26.6, arm64

Terminal

cmux (Ghostty-based)

[argszero]

I would like to work on this.

The report points at the server side pending input queue rather than the TUI: queued prompts are session pending rows (packages/core/src/session/pending.ts), and packages/tui only lists them through session.pending.list (packages/tui/src/context/data.tsx). A command whose delivery is interrupted by an auto-compaction then looks like a pending row that is never consumed, so every later compaction pass promotes it again, which matches the repeated message=command lines for hours on one run= id.

Plan: reproduce it as a session level test around pending promotion with an interrupted delivery, then fix the consume path so a command that was already delivered cannot be promoted again. I will confirm the shape against current v2 first and post the reproduction, or a not reproducible finding, here before sending a PR.

Context: this is the sibling of #51223 and #51224 from the same session timeline. I looked at #51224 earlier and stepped back from it because the intended semantics of concurrent asks are a maintainer decision. This one is a plain state bug, so I am picking it up.

[argszero]

Correction to the comment above, before anyone relies on it: this report is version 1.18.32, which is the dev line, so the queue here is not the packages/core/src/session/pending.ts row model I named (that is the 2.0.x line). The message=command line in the report is emitted by SessionPrompt.command in packages/opencode/src/session/prompt.ts, so the replay lives on the 1.18.x side: how a message or command submitted while a run is active is held, and why an auto-compaction leaves it deliverable again.

I will pin the exact site with a reproduction first and report back here before sending a PR.

[argszero]

Code-reading notes while trying to reduce this (dev line, i.e. 1.18.33). Posting them because two of them narrow the search a lot, and one may explain the whole report.

1. Which TUI produced this? There are two interactive clients, and only one of them has a visible prompt queue.

• Classic TUI (opencode): the only session.command call site is packages/tui/src/component/prompt/index.tsx:1083. It fires the request and returns immediately. There is no client-side prompt queue in that package, and packages/tui/src/config/keybind.ts:102 only declares session_queued_prompts in the shared keybind schema.
• Split-footer TUI (opencode --mini): this is where the queue lives - packages/opencode/src/cli/cmd/run/runtime.queue.ts, with session.queued_prompts bound in packages/opencode/src/cli/cmd/run/footer.view.tsx:557, the QUEUED/queued-menu UI, and local edit/removal of queued follow-ups.

In the classic TUI the badge that reads QUEUED is not a queue entry at all: packages/tui/src/routes/session/index.tsx:243 computes it from assistant messages that have not completed, so a user message submitted while busy is simply rendered after the in-flight assistant message.

So the first question is which client was running. If it was --mini, the replay is client-side and I would look at that queue first. If it was the classic TUI, the re-submission cannot come from the prompt component, and the sender is something else on the same machine.

2. Each message=command command=<name> line is exactly one HTTP POST. That line is the entry log of SessionPrompt.command (packages/opencode/src/session/prompt.ts:1357), so the excerpt proves four separate requests reached POST /session/{id}/command - it does not show one request re-entering itself. Matching those four timestamps against the TUI/server access log would separate "server replays" from "client re-sends" immediately.

3. Why a command looks like it waits for the compaction. SessionPrompt.command stores the user message straight away and then enters the loop; the loop goes through SessionRunState.ensureRunning (packages/opencode/src/effect/runner.ts:115). While a session is Running, a second submission is not queued as work - it parks on the running turn's completion deferred and the running loop picks the new user message up when it re-reads the session on its next iteration. That is the follow-up behaviour: no queue object exists, the message is durable and the POST stays open until the current turn (the compaction) finishes. It also explains the timing you saw (a few seconds after compaction, or at the next idle).

4. Retry and idempotency. Nothing in the classic path retries: packages/tui/src/context/sdk.tsx only retries the global event stream, packages/sdk/js/src/v2/client.ts has no retry, and packages/opencode/src/cli/tui/worker.ts proxies each fetch once. CommandInput.messageID is optional and createUserMessage honours it (packages/opencode/src/session/prompt.ts:657), but the classic TUI does not send one - so two POSTs of the same slash command produce two distinct user messages and two full command executions, which matches the duplicate text your command-dedup plugin annotates. The split-footer TUI does send a stable messageID per queued prompt (packages/opencode/src/cli/cmd/run/stream.transport.ts:1285), so for that path a client re-send reuses the message id, but the command still re-executes because the loop runs regardless.

5. What would settle it. Three things I cannot observe from here:

• Which client: plain opencode or opencode --mini?
• Do the affected sessions contain duplicate user messages with the same command text and the same command name (GET /session/{id}/message)?
• If --mini: is the session queue actually empty at the moment the next compaction starts (<leader>q), and does the re-submission stop if you clear it?

I am still on this one; if the client turns out to be the classic TUI, the next thing I would instrument is the request log to catch the second sender.

[rekram1-node]

this is fixed on v2:
https://opencode.ai/v2/docs