Repository navigation
prompt_async does not wake idle sessions (noReply: false returns 204 but no assistant turn) #21524
Description
Summary
POST /session/{id}/prompt_async with noReply: false returns HTTP 204 but does not reliably trigger a new assistant turn when the session is idle. The message is accepted at the HTTP layer but the orchestration loop does not engage.
Steps to Reproduce
- Start an OpenCode session, let it complete its current task and go idle (waiting for user input)
- POST to
/session/{sessionID}/prompt_asyncwith:{"noReply": false, "parts": [{"type": "text", "text": "Please respond to this message."}]} - Observe: HTTP 204 returned, but the session stays idle. No assistant response is generated.
- Manually type into the session → the injected message appears in history but was never acted on.
Expected Behavior
With noReply: false, the injected prompt should trigger a new assistant turn, just as if the user had typed it.
Context
We're building a multi-agent messaging system (relay-mesh) where agents running in different OpenCode sessions communicate via MCP tools. When Agent A sends a message to Agent B, we use prompt_async to notify B. This works when B is actively working (mid-tool-call), but fails when B is idle.
The behavior is intermittent — sometimes the session does wake up, sometimes it doesn't. This suggests a race condition in the session state machine rather than a fundamental design limitation.
Related Issues
- TUI doesn't render messages from prompt_async endpoint #8564 — TUI doesn't render messages from prompt_async
- /session/status potentially not reporting properly #12860 — /session/status not reporting properly after prompt_async
- Sessions hang indefinitely when Task tool spawns subagents via REST API (opencode serve) #6573 — Sessions hang with REST API subagents
Environment
- OpenCode v1.3.17
- Linux (Ubuntu 24.04)
- Multiple concurrent sessions via shared OpenCode server
Activity
github-actions commentedon Apr 8, 2026
This issue might be a duplicate of existing issues. Please check:
prompt_asyncwhere session cancel races caused lost/failed prompts (related root cause area)OverHash commentedon Apr 14, 2026
Hi! I'm also experiencing this.
In my case, I send the third user message, which then triggers a chain of assistant messages. However, once the assistant is done, I send a new message immediately (no
session.idleis triggered).Unfortunately, it looks like OC transitions from there to the idle session state, and so the assistant never responds to my latest message (at the bottom). As a result, my bottom message has no action taken.
To be clear, my chain is
finish:"stop"(on the assistant message to my first user message) -> promptAsync second turn ->session.idle-> no parent message.updated.github-actions commentedon Jul 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
Ghilteras commentedon Jul 27, 2026
Why this bug is closed as not planned?