[BUG] Assistant ends the turn announcing work it never starts — silent no-op, user must poll to discover it

What happened

In a long working session (Opus 5, Ultracode on), the assistant repeatedly ended its turn announcing work it then never started. The final assistant message says "Doing it now" / "Starting" / "Continuing", contains no tool calls, and the turn closes. From the user's side nothing happens: no edits, no background task, no progress — until they ask again.

This happened at least six times in one session, always at the same structural point: right after a long explanatory reply, when the next step was a large multi-step edit.

Reproduction

Not input-dependent, but it reproduces reliably under this shape of work:

1. Long session (100+ turns), large document under iterative revision (~128k chars).
2. Assistant produces a long analytical answer (a review verdict, a numbered findings list).
3. User says "go ahead / fix it".
4. Assistant replies with one line of intent — "Fixing now", "Starting with the money circuit" — zero tool calls, turn ends.
5. User waits, then asks "are you doing anything?" — assistant confirms it did nothing and starts.

Verbatim examples from the session (translated):

• User: "go ahead" → Assistant: "Silently. I'll tell you when the judge says it passes." → turn ends, no tool calls
• User: "are you working? looks like you're not" → Assistant: "Correct, I didn't. Doing it now." → then actually works
• User: "you're not doing anything right now, correct?" → Assistant: "Correct. I said 'doing it' and stopped."

What I expected

If the assistant states it is performing an action in the same turn, the turn should contain the corresponding tool calls — or the assistant should say explicitly that it is handing the turn back.

Why it matters

The failure is silent and asymmetric. A crash is visible; this looks exactly like work in progress. The user's only recovery is to poll ("are you doing anything?"), and each poll costs a full round trip. In a session where the user asked six times, that is six wasted turns plus the wall-clock time they spent waiting on nothing.

It also erodes trust in a specific way: after two or three occurrences the user cannot distinguish "working" from "stopped", so every status claim needs manual verification.

Suspected cause

Speculation, but the pattern is consistent: the turn-ending decision seems to be made after the intent sentence is emitted, and long preceding context (a 200k-token judge report pasted into the turn) appears to raise the odds. It behaves like the model treating the announcement itself as the deliverable — closer to a stop-condition mis-evaluation than to a refusal.

Notably, a Stop hook in this session forced a follow-up question ("did you edit docs?"), which sometimes resumed the work — suggesting the model was willing to continue and simply concluded the turn early.

Environment

• Claude Code, Windows 11 Pro 10.0.26200, PowerShell + Git Bash
• Model: Opus 5 (claude-opus-5), Ultracode enabled, bypass permissions mode
• Session length at time of occurrences: 100+ turns, several compactions
• Reproduced across compaction boundaries, so it is not a single corrupted context

Suggested mitigation

Any of these would remove the silent failure:

1. Treat a turn whose final message asserts in-progress action but contains no tool call as incomplete, and continue.
2. Surface it to the user: if the assistant's closing message states intent without acting, show a hint that the turn ended without tool use.
3. Model-side: bias toward emitting the first tool call before the intent sentence, not after.

Option 2 alone would be enough — the user needs to see that nothing is running, not to guess it.