ACP: scheduled (cron) turns emit no session/update events, so clients cannot tell the session is busy

Environment

• kimi-code 0.36.1, launched as kimi acp over stdio
• Model kimi-code/k3, thinking effort high
• Linux x86_64; the client is a custom ACP client (session multiplexer)

What happened

Our agent created an hourly cron job for itself (47 * * * *) using the built-in cron feature, to babysit a long fuzzing campaign.

Timeline (UTC, 2026-08-17):

1. 03:47 — the cron fired. kimi-code started a long scheduled turn: kimi-code.log shows steady llm request/response turnStep=5.x telemetry and the process spawns tool subprocesses (cargo test, sleep 290 wait-polls). The turn ran for well over 45 minutes and was healthy the whole time.
2. 04:22:52 — the user sent a session/prompt ("status?"). kimi-code accepted it and queued it behind the scheduled turn. That queuing behavior is fine.
3. 04:22 → 04:34+ — zero session/update notifications arrived over ACP. Not for the scheduled turn's activity, and no signal that a scheduled turn was running at all.

The problem

From the client side the session is indistinguishable from a hung agent: the prompt was accepted, the timer climbs, and nothing ever arrives. We only established that the agent was busy (not broken) by logging into the machine and reading kimi-code.log and the process table.

Everything kimi-code was doing — LLM steps, tool calls — is exactly the material session/update exists to carry. It just is not emitted for scheduled turns.

Suggested fix

Either of these would resolve it:

1. Minimal: emit a session/update (or a _meta notification) when a scheduled turn starts and ends. That alone lets a client render "busy with scheduled task" and explain why an interactive prompt is waiting.
2. Better: stream scheduled-turn activity as normal session/update notifications. They are session-scoped notifications, so this fits the wire format; if there is concern about clients that assume updates only occur inside a prompt turn, gate it behind a client capability flag at initialize time.

We recognize ACP's docs frame session/update as part of prompt processing and the spec has no concept of agent-initiated turns — but kimi-code already runs such turns, so some visibility signal is needed for any ACP client to present them sanely.

Start at the kimi acp scheduled-turn and ACP session/update handling, comparing cron-triggered turns with session/prompt processing. Review the initialize capability context mentioned in the issue and trace where scheduled activity could become session-scoped notifications. Done means an ACP client can distinguish an active scheduled turn from a hung session and receives appropriate updates or start/end signals.