turn_end reports "could not resolve the persisted assistant entry ID" when the loop normalizes a response's stop reason #3029

What happened

With any extension that registers a turn_end handler (for example the omo plugin), some turns print:

Extension "<boundary>" error: turn_end could not resolve the persisted assistant entry ID

The session keeps going, but every turn_end handler is skipped for that turn. This is not the mid-turn shutdown case from #2995; it happens in a live session.

Cause

runLoop in packages/agent/src/agent-loop.ts normalizes the response's stop reason only after streamAssistantResponse has emitted message_end:

const message = demoteToolUseWithoutToolCalls(promoteStopWithPendingToolCalls(streamed.message));

Both helpers return a new object when they change something. That happens when a provider ends with stop while tool calls are pending (the Cursor shape promoteStopWithPendingToolCalls exists for), or with toolUse and no tool call. finishTurn and turn_end then get a copy that was never persisted. AgentSession._findPersistedMessageEntryId looks the message up by identity (_entryIdsByMessage, the branch, agent.state.messages), finds nothing, and emits the <boundary> error.

As a side effect, message_end, agent state and the session file keep the raw stop reason, while finishTurn and turn_end see the normalized one.

Repro

Faux provider plus one turn_end handler. The first response is fauxAssistantMessage(fauxToolCall("noop", {}), { stopReason: "stop" }) (or fauxAssistantMessage("done", { stopReason: "toolUse" })); then session.prompt("go"). On main (6523490), the extension runner reports the <boundary> error once for that turn.

Expected

message_end carries the already-settled stop reason, and finishTurn and turn_end receive that same object, so turn_end handlers always get messageEntryId.

Version: 2026.10.10-6 (same code on main). I have a fix with tests and will open a PR.

Drafted with an AI coding agent.