TurnStarted hook can run after the same turn's Stop hook (fire-and-forget vs awaited) #4141

What version of Kimi Code is running?

2.1.1 (npm @moonshot-ai/kimi-code). The code path is unchanged on main at 21406fb.

Which open platform/subscription were you using?

A local OpenAI-compatible test server (custom provider)

Which model were you using?

A scripted test model that answers immediately

What platform is your computer?

Windows 10 (10.0.19045), x64

What issue are you seeing?

External hook events for one turn can reach hook commands in the wrong order. On a fast turn, the TurnStarted hook runs after the Stop hook of the same turn.

In packages/agent-core-v2/src/features/externalHooks/agent/agentExternalHooksService.ts, TurnStarted goes through fireAndForget (notifyTurnStarted), while Stop is awaited (runner.triggerBlock in onDidFinishStep). Both start a separate process, and nothing orders the fire-and-forget one before the awaited one. When the model answers in well under a second, the Stop process often finishes first.

A consumer that tracks turns from hooks then sees "turn ended" followed by "turn started" and is left thinking a turn is still running. Stop carries no turnId, so the consumer can't tell that the late TurnStarted belongs to the turn that already ended.

What steps can reproduce the bug?

1. In config.toml, add two [[hooks]] entries, TurnStarted and Stop. Each runs a command that appends the event name and a high-resolution timestamp to the same file (for example, an HTTP POST to a local listener that logs arrival order).
2. Use a provider that answers immediately (a local stub or a trivial prompt on a fast model).
3. Send several short prompts in the interactive TUI.
4. Check the log. For some turns, Stop is logged before TurnStarted.

We saw this with hooks that POST to a loopback HTTP listener (curl, cmd.exe on Windows). On sub-second turns, the late TurnStarted regularly arrived after Stop.

What is the expected behavior?

For a given turn, TurnStarted is delivered before Stop/StopFailure/Interrupt. If keeping it fire-and-forget matters, then Stop, StopFailure and Interrupt should carry the same turnId that TurnStarted has, so consumers can match the events and drop a stale start.

Additional information

Context: we run Kimi Code in a desktop app (NeuroSquad) and show each session's status from its hooks. For turns the user types, we rely on UserPromptSubmit (awaited). TurnStarted is the only start signal for turns nobody typed (background task notifications, schedules), and that's where the reordering leaves a session stuck at "working".

Two possible fixes: dispatch TurnStarted through the awaited path like UserPromptSubmit (it doesn't block), or add turnId to the end-of-turn payloads (notifyTurnEnded already has event.turnId; runStop doesn't pass it).