Summary
When the agent is blocked on an interactive question tool prompt and the user sends a new message (instead of answering the prompt inline), the message is persisted but never processed: the agent loop dies silently, no follow-up turn happens, and there is no abort/error event. From the user's perspective the session "aborts" and never answers.
Repro (v1.18.18, TUI, model glm-5.2 via neuralwatt provider)
- Start a session, give the agent a task that ends with a
question tool call (e.g. a confirmation prompt before a live config publish).
- When the prompt is on screen (
message=asking id=que_... questions=1 in the log), type a new message in the input box (e.g. "So?") and submit — do not answer the prompt inline.
- Expected: the message either answers the pending question or queues for the next loop iteration, and the agent continues.
- Actual: the message lands in the
message table (role=user, text part), nothing else happens. No step-finish on the interrupted assistant turn, no reply, no session.aborted/error event, session_inbox stays empty, and the log's last line is the asking line. The session's time_updated equals the user message's timestamp and never advances.
Evidence (SQLite at ~/.local/share/opencode/opencode.db)
- Last assistant turn parts:
step-start, reasoning, text, tool with the question tool in state.status: "running" — no step-finish.
- Following user message:
role=user, part type text ("So?"), time_created = session time_updated.
event table for the session: only session.created/updated + message.* rows. No abort/cancel/interrupt/error row.
session_inbox: empty.
log/opencode.log tail: ends at message=asking id=que_... questions=1; nothing after the user message.
Impact
Any interactive question prompt (password/confirmation flows) is a dead-end trap: the user's reply-as-message is silently dropped and the whole run is lost. Workaround today: answer the prompt inline, or resume the session and hope the message becomes a normal turn (it did not in this case).
Environment
- OpenCode v1.18.18 (TUI), Linux, session id
ses_fb2859be9ffejkHLBv6KQb96Ws
- Happened in a plain interactive session (cwd
/home/marcelloc/git/cuplegends)
Summary
When the agent is blocked on an interactive
questiontool prompt and the user sends a new message (instead of answering the prompt inline), the message is persisted but never processed: the agent loop dies silently, no follow-up turn happens, and there is no abort/error event. From the user's perspective the session "aborts" and never answers.Repro (v1.18.18, TUI, model glm-5.2 via neuralwatt provider)
questiontool call (e.g. a confirmation prompt before a live config publish).message=asking id=que_... questions=1in the log), type a new message in the input box (e.g. "So?") and submit — do not answer the prompt inline.messagetable (role=user,textpart), nothing else happens. Nostep-finishon the interrupted assistant turn, no reply, nosession.aborted/error event,session_inboxstays empty, and the log's last line is theaskingline. The session'stime_updatedequals the user message's timestamp and never advances.Evidence (SQLite at ~/.local/share/opencode/opencode.db)
step-start, reasoning, text, toolwith thequestiontool instate.status: "running"— nostep-finish.role=user, part typetext("So?"),time_created= sessiontime_updated.eventtable for the session: onlysession.created/updated+message.*rows. No abort/cancel/interrupt/error row.session_inbox: empty.log/opencode.logtail: ends atmessage=asking id=que_... questions=1; nothing after the user message.Impact
Any interactive
questionprompt (password/confirmation flows) is a dead-end trap: the user's reply-as-message is silently dropped and the whole run is lost. Workaround today: answer the prompt inline, or resume the session and hope the message becomes a normal turn (it did not in this case).Environment
ses_fb2859be9ffejkHLBv6KQb96Ws/home/marcelloc/git/cuplegends)