[BUG] Desktop Code tab: next-step box (wrap_up with an ask) can end the turn before the reply is written

Environment

• Claude Desktop for Windows 2.37337.1.0, Code tab, local session
• Claude Code 2.1.295 (bundled), model claude-opus-5-5
• Windows 11

What happens

The Code tab's new next-step box is drawn when the model calls the wrap_up turn tool with an ask and actions. When the box shows a question, the tool result tells the model that the box ends the turn and that it must write no text after the call.

Nothing checks that the reply was written before the call. In one evening session the model called wrap_up with an ask three times before writing its answer. Each time the user got a two-sentence recap and two buttons, and none of the findings they had asked for (a changelog summary, a hooks review). The model could only deliver the answer by writing text after the call, against the tool's own instruction.

A second, related case: the model called wrap_up twice in one turn. The second call carried only a recap, and it silently replaced the first call's box, so the question and buttons disappeared. The result of the first call says "Do not call wrap_up again this turn", but the second call is accepted anyway.

Steps to reproduce

1. In a Code tab session, ask for something that needs a long answer plus a decision (for example: "read this changelog and tell me what affects my setup").
2. The model does the research, then calls wrap_up with recap, ask and actions before writing its reply text.
3. The box appears and the turn ends. The user sees the recap and the buttons, but not the answer.

For the second case: call wrap_up with an ask, then call it again in the same turn with only a recap. The box from the first call is gone.

Expected

The tool enforces its own contract instead of relying on the model to remember the order:

• wrap_up with an ask refuses when the current turn has no assistant text since the user's last message, or only a line or two, and says why ("write the reply first, then call wrap_up"). Nothing is drawn, so the model can retry in the right order.
• A second wrap_up call in the same turn is refused, rather than replacing the first box.

Instructions don't hold this reliably: the same model got the order wrong three times in one session while the instruction was in its tool description and in its tool results. A refusal at the tool boundary would.