prompt_async on a busy session persists the message but never schedules a turn

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

1. Start a long agentic turn on a session (sync prompt is fine).
2. While it runs, POST /session/:id/prompt_async the same session.
3. The endpoint returns 204 and the user message is persisted.
4. 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)