Name a still-running cancelled command on the next call to any tool
When an agent's turn stops while a foreground command is still running, the command keeps going as a background task. AFT used to name it only on the session's next shell-family call (bash, bash_status, ...). It now names it once on the next agent-visible reply of any tool, for example read or aft_search. Ufuk approved this behaviour; ALF reported the gap.
Notices stay pending, not consumed, through replies the agent never sees: plugin plumbing polls (bash_status with task_id), previews, held permission asks, and refused calls (argument and translation refusals keep their existing path).
Tests (through real subc routing and the standalone tool_call path): the notice appears exactly once on the next read; it survives a native status poll, an argument refusal, a held access ask and a preview; a later status check doesn't repeat it; the agent's taskId spelling of bash_status still receives it. The owner-cancellation test now expects the notice on read. 42 filtered tests pass on Linux; Windows target check with -D warnings passes.
Summary by cubic
Names a still-running cancelled command on the next agent-visible reply of any tool instead of only the next shell-family call. When an agent's turn stops while a foreground command keeps running as a background task, the notice now appears once on replies like read or aft_search.
Tests
- The notice appears exactly once on the next
read, survives native status polls, argument refusals, held access asks, and previews, and is not repeated by later status checks. - The owner-cancellation test now expects the notice on
read.