Background subagent delegation stalls the coordinator turn; agents intermittently lost (task.lost)

Summary

When the main agent delegates a subagent with run_in_background=true, the coordinator intermittently freezes (turn hangs, no streaming, no tool activity), and background agents occasionally end as task.lost with no result. This makes the multi-agent workflow (parallel subagents) unreliable in the TUI.

Observed

• Lead calls Agent(run_in_background=true, subagent_type=...) → tool returns a task id immediately (correct), but the lead's turn then stalls instead of continuing.
• Later, a task.lost notification arrives for the subagent ("Background agent lost … its conversation history is preserved across session restarts") with no result ever delivered. In the same session, the subagent had produced no output before being lost.
• ~/.kimi-code/sessions/<wd>/session_*/agents/agent-N/wire.jsonl for the lost agent exists but the main wire shows no completion event for the task.

Environment

kimi-code 0.30.0 (Homebrew), macOS, interactive TUI, yolo mode, [background] max_running_tasks unset (default 4).

Code pointers (dist/main.mjs, 0.30.0)

Places worth profiling, from a static read:

1. AgentTool spawn path (this.subagentHost.spawn(...)) is awaited inline before registerTask — if spawn does MCP/skill/agent discovery (mcp.waitForInitialLoad is called in the step loop), a background launch pays that cost on the lead's turn.
2. backgroundManager.registerTask(...) → runTaskLifecycle(entry) is called synchronously at registration; any synchronous persistence (persistLive, outputWriteQueue) on the main loop would block the turn.
3. The foreground/background split happens in waitForForegroundRelease / formatForegroundResult; the background path returns via formatBackgroundAgentResult — but the freeze occurs after the tool result is returned, which points at the turn loop or the completion-notification/steer machinery rather than the tool itself.
4. task.lost is emitted by the ghost-reconcile path ("lost tasks from a prior CLI process") — suggesting the subagent task's process/heartbeat died without the manager noticing in time.

Comparison with Claude Code 2.1.220

• Claude ships a Monitor tool ("stream events from a background process") so the lead can observe a background agent without blocking; kimi has no equivalent (only TaskOutput snapshots).
• Claude delivers completion via a task_notification (completed/failed/stopped) message type; kimi injects a synthetic user-role message that forces a new turn — which may contribute to the perceived stall when it lands mid-work.

Asks

1. A way to diagnose: a debug flag/log for the background task lifecycle (spawn → register → lifecycle → completion) so we can attach a trace.
2. Ideally: make spawn non-blocking for the lead turn (defer discovery to the subagent's own loop), and surface a non-turn-stealing completion signal.
3. Consider a Monitor-style streaming tool for background agents.

Happy to provide session wires privately if useful.

Start by profiling the AgentTool spawn path, backgroundManager.registerTask/runTaskLifecycle, waitForForegroundRelease, and the ghost-reconcile path in dist/main.mjs. Trace spawn, registration, lifecycle, completion, and task.lost events in a reproduction; done means the coordinator continues reliably and background completion or loss is observable without an unexplained stall.