A message sent just before a foreground bash wait starts never detaches it #465

AFT: 0.59.0 · Host: OpenCode V2 (2.0.28)

What happens

detach_on_user_message only checks for a waiting bash at the moment the message is submitted. If the model is still generating the tool call when the message arrives, there is nothing to detach yet. The wait: true command then starts and runs in the foreground until it finishes, while the user's message sits pending.

Sending the same message a few seconds later, after the command has started, works as documented: the wait moves to the background and the message is handled at once.

Timeline (from aft-plugin.log and the session's messages, UTC)

The message was pending for about 95 s. The same log shows the detach succeeding when the message arrives during the wait (detached=true … detached wait for session …, 2026-10-15 13:21:13 and 19:58:13).

Why

The detach is triggered from the V2 session prompt hook (V1: chat.message). Both fire once, when the message is admitted (interruptBashWaitsForChatMessage → signalBashWaitDetachForProject). Nothing re-checks when a foreground wait begins afterwards. So this applies on V1 too, not only V2.

Expected

A message that arrived after the current step started, and is still pending when a foreground wait begins, should detach that wait as if it had arrived during it. In other words, the wait starts already detached (or detaches immediately).

Possible approach

When a sync wait starts, check for a pending message for that session. Two ways to know:

• AFT records "message arrived, nothing to detach" per session and clears it at the next step boundary or user turn. This needs no host API.
• The host exposes pending-input state or an event. V2 holds this in its session inbox, but I'm not aware of a plugin-facing API for it.

The first seems enough, as long as the flag is cleared once the message is delivered, so a later wait in a new turn isn't detached by mistake.

Impact

It's a delay, not data loss: the message waits for that one command. It is long when the command is long (a build or deploy with a 20-minute timeout). The window is narrow, the few seconds while the model writes the call, so it's intermittent and hard to notice.