Summary
An agent running on the Kimi (ACP) runtime stops executing mention-triggered tasks: the daemon dispatches the task, the agent process exits after ~1s with tools=0, and the task is marked completed with no output and no error anywhere. From the user's perspective the agent simply never works again, while other runtimes (codex, grok) on the same daemon keep working.
Environment
multica CLI / daemon: 0.4.7
Runtime: Kimi (kimi-code 0.28.1, ACP mode), kimi acp
macOS, Apple M4
Setup: a squad where a leader agent delegates to members by @-mentioning them in issue comments
What happens
The kimi-backed agent works normally for its first few mention-triggered tasks (each task resumes the same kimi session, reused=true).
From some point on, every mention task for that agent shows this pattern in multica daemon logs and nothing else:
task received / picked task agent=内容创作助手 provider=kimi
starting agent ... provider=kimi reused=true
resuming session ... session_id=session_e165e5b4-...
agent finished ... status=completed duration=1s tools=0
task completed ... status=completed
No comment is posted, no error is logged (daemon, session log, or issue timeline). The task is reported as successfully completed. This repeated 4/4 times until we intervened.
Root cause (confirmed by manual repro)
Resuming the exact same session manually reproduces it:
$ kimi -S session_e165e5b4-... -p "ping"
error: failed to run prompt: provider.api_error: 400 the message at position 43 with role 'assistant' must not be empty
Inspecting the session's wire.jsonl shows the last persisted assistant step of the previous turn contains only an empty thinking part and nothing else:
{"type":"content.part","turnId":"2","step":6,"part":{"type":"think","think":""}}
When the session is resumed, the rebuilt request includes that final assistant message with empty content, the API rejects it with 400, and every subsequent resume of this session fails the same way — the session is permanently bricked while the daemon keeps resuming it.
So there are two bugs:
kimi-code side: a think-only (empty) assistant message gets persisted as the last message of a session, making all future requests from that session invalid (400). Empty assistant messages should never be persisted (or should be repaired/dropped on resume).
Multica daemon side: when the ACP turn fails this way, the daemon records the task as status=completed with tools=0 and no output. The LLM 400 is swallowed completely — no agent_error, no failed status, no log line. Expected: task marked failed with the provider error visible, and ideally a fresh session retry instead of endlessly resuming a broken session.
Workaround (verified)
Editing the session's wire.jsonl and replacing the final empty think part with a non-empty text part un-bricks the session; the agent executes normally on the next mention.
Suggested fixes
kimi-code: never persist an assistant message whose content is empty (think-only with empty text); or sanitize history on resume before sending.
daemon: surface ACP/provider errors as task failures (include agent_error in logs and the task record), and consider resetting to a fresh session when resume repeatedly fails.
Summary
An agent running on the Kimi (ACP) runtime stops executing mention-triggered tasks: the daemon dispatches the task, the agent process exits after ~1s with tools=0, and the task is marked completed with no output and no error anywhere. From the user's perspective the agent simply never works again, while other runtimes (codex, grok) on the same daemon keep working.
Environment
multica CLI / daemon: 0.4.7
Runtime: Kimi (kimi-code 0.28.1, ACP mode), kimi acp
macOS, Apple M4
Setup: a squad where a leader agent delegates to members by @-mentioning them in issue comments
What happens
The kimi-backed agent works normally for its first few mention-triggered tasks (each task resumes the same kimi session, reused=true).
From some point on, every mention task for that agent shows this pattern in multica daemon logs and nothing else:
task received / picked task agent=内容创作助手 provider=kimi
starting agent ... provider=kimi reused=true
resuming session ... session_id=session_e165e5b4-...
agent finished ... status=completed duration=1s tools=0
task completed ... status=completed
No comment is posted, no error is logged (daemon, session log, or issue timeline). The task is reported as successfully completed. This repeated 4/4 times until we intervened.
Root cause (confirmed by manual repro)
Resuming the exact same session manually reproduces it:
$ kimi -S session_e165e5b4-... -p "ping"
error: failed to run prompt: provider.api_error: 400 the message at position 43 with role 'assistant' must not be empty
Inspecting the session's wire.jsonl shows the last persisted assistant step of the previous turn contains only an empty thinking part and nothing else:
{"type":"content.part","turnId":"2","step":6,"part":{"type":"think","think":""}}
When the session is resumed, the rebuilt request includes that final assistant message with empty content, the API rejects it with 400, and every subsequent resume of this session fails the same way — the session is permanently bricked while the daemon keeps resuming it.
So there are two bugs:
kimi-code side: a think-only (empty) assistant message gets persisted as the last message of a session, making all future requests from that session invalid (400). Empty assistant messages should never be persisted (or should be repaired/dropped on resume).
Multica daemon side: when the ACP turn fails this way, the daemon records the task as status=completed with tools=0 and no output. The LLM 400 is swallowed completely — no agent_error, no failed status, no log line. Expected: task marked failed with the provider error visible, and ideally a fresh session retry instead of endlessly resuming a broken session.
Workaround (verified)
Editing the session's wire.jsonl and replacing the final empty think part with a non-empty text part un-bricks the session; the agent executes normally on the next mention.
Suggested fixes
kimi-code: never persist an assistant message whose content is empty (think-only with empty text); or sanitize history on resume before sending.
daemon: surface ACP/provider errors as task failures (include agent_error in logs and the task record), and consider resetting to a fresh session when resume repeatedly fails.