Repository navigation
prompt_async on a busy session persists the message but never schedules a turn #46842
Description
Description
When POST /session/:id/prompt_async lands while the session's runner state is Running, the user message is persisted but its turn never runs.
promptAsync (server/routes/instance/httpapi/handlers/session.ts) forks prompt() and returns 204 immediately. prompt() (session/prompt.ts) persists the user message, then calls loop() → ensureRunning() (effect/runner.ts), which on Running returns awaitDone(st.run.done) — the forked fiber waits for the existing run and returns its result, so the new message's runLoop never executes.
Observed in production over a week of programmatic use: async prompts sent during long agentic turns are persisted (visible via GET /session/:id/message) but never answered, unless the running loop happens to re-read messages between tool rounds and absorbs them.
Plugins
None (core server behavior).
OpenCode version
dev as of 2026-09-02 (verified against source; observed on v1.18.x)
Steps to reproduce
- Start a long agentic turn on a session (sync prompt is fine).
- While it runs,
POST /session/:id/prompt_asyncthe same session. - The endpoint returns 204 and the user message is persisted.
- When the turn ends, no reply is generated for the async message.
Screenshot and/or share link
n/a — transcript state: async user message present, no assistant response after it, session idle.
Operating System
Linux
Terminal
n/a (server API)
Activity
github-actions commentedon Sep 2, 2026
This issue might be a duplicate of existing issues. Please check:
If these are distinct root causes (busy-session
ensureRunningpath vs. idle-session scheduling race), it may be worth linking them for cross-reference rather than closing as a duplicate.neriousy commentedon Oct 19, 2026
This is fixed in v2: new prompts enter a durable session inbox, and a prompt arriving while the session is running records a pending wake instead of only joining the existing run. The runner drains again before going idle, so accepted work is not stranded by the old busy-session scheduling path.
To get v2, run
npm i -g @opencode/cli@latest. If you still see this on v2, please open a new issue with the details.