[ACP/Zed] Two UX issues: missing YOLO mode support & silent failure on API errors

Bug Description

I've been using kimi-cli in both standalone CLI mode and via Zed ACP integration. Compared to Claude Code ACP, there are two significant UX gaps when using kimi-cli through ACP (specifically in Zed):

Issue 1: YOLO mode not exposed via ACP protocol

Current behavior:
When using kimi-cli as an ACP agent (e.g., in Zed), there's no way to enable YOLO mode through the client UI. The /yolo command works in terminal mode, but the ACP protocol implementation doesn't seem to expose this capability to clients.

Expected behavior:
kimi-cli should expose YOLO mode toggle through the ACP protocol so clients like Zed can provide UI controls (similar to how Claude Code ACP does it).

Issue 2: Silent failure on Moonshot API errors (e.g., high-risk content refusal)

Current behavior:
When the Moonshot CN service returns certain errors (e.g., "high-risk text refused" content policy violation), kimi-cli in ACP mode appears to:

1. Not properly propagate the error to the ACP client
2. Enter a state where subsequent commands are silently ignored
3. Give the user no indication of what went wrong

The Zed UI just appears to stop responding to new messages without any error feedback.

Expected behavior:
kimi-cli should:

1. Properly report API errors through the ACP protocol
2. Display clear error messages to the user explaining the failure
3. Either recover gracefully or clearly indicate that the session needs restart

Environment

Component Version
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
OS macOS 26.3.1 (a) / Darwin 25.3.0
Architecture ARM64 (Apple Silicon)
kimi-cli 1.24.0
Zed (please fill in: Cmd+Shift+P → "zed: about")

Steps to Reproduce

Issue 1:

1. Configure kimi-cli as ACP agent in Zed (kimi acp)
2. Start a new thread in Zed Agent Panel
3. Look for YOLO mode toggle → missing

Issue 2:

1. Start kimi-cli ACP session in Zed
2. Send a message that triggers content policy (e.g., topics flagged as high-risk by Moonshot CN)
3. Observe: no error shown in Zed UI, but subsequent messages are ignored

Additional Context

• Standalone CLI mode works fine: /yolo command exists and functions correctly
• Claude Code ACP integration in Zed does expose YOLO mode toggle, suggesting this is an ACP protocol implementation gap in kimi-cli
• The silent failure makes the Zed integration frustrating when content policy issues occur

──────────────────────────────────────────────────────────────────

---

Bug Description

I've been using kimi-cli in both standalone CLI mode and via Zed ACP integration. Compared to Claude Code ACP, there are two significant UX gaps when using kimi-cli through ACP (specifically in Zed):

Issue 1: YOLO mode not exposed via ACP protocol

Current behavior:
When using kimi-cli as an ACP agent (e.g., in Zed), there's no way to enable YOLO mode through the client UI. The /yolo command works in terminal mode, but the ACP protocol implementation doesn't seem to expose this capability to clients.

Expected behavior:
kimi-cli should expose YOLO mode toggle through the ACP protocol so clients like Zed can provide UI controls (similar to how Claude Code ACP does it).

Issue 2: Silent failure on Moonshot API errors (e.g., high-risk content refusal)

Current behavior:
When the Moonshot CN service returns certain errors (e.g., "high-risk text refused" content policy violation), kimi-cli in ACP mode appears to:

1. Not properly propagate the error to the ACP client
2. Enter a state where subsequent commands are silently ignored
3. Give the user no indication of what went wrong

The Zed UI just appears to stop responding to new messages without any error feedback.

Expected behavior:
kimi-cli should:

1. Properly report API errors through the ACP protocol
2. Display clear error messages to the user explaining the failure
3. Either recover gracefully or clearly indicate that the session needs restart

Environment

Component Version
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
OS macOS 26.3.1 (a) / Darwin 25.3.0
Architecture ARM64 (Apple Silicon)
kimi-cli 1.24.0
Zed (please fill in: Cmd+Shift+P → "zed: about")

Steps to Reproduce

Issue 1:

1. Configure kimi-cli as ACP agent in Zed (kimi acp)
2. Start a new thread in Zed Agent Panel
3. Look for YOLO mode toggle → missing

Issue 2:

1. Start kimi-cli ACP session in Zed
2. Send a message that triggers content policy (e.g., topics flagged as high-risk by Moonshot CN)
3. Observe: no error shown in Zed UI, but subsequent messages are ignored

Additional Context

• Standalone CLI mode works fine: /yolo command exists and functions correctly
• Claude Code ACP integration in Zed does expose YOLO mode toggle, suggesting this is an ACP protocol implementation gap in kimi-cli
• The silent failure makes the Zed integration frustrating when content policy issues occur

──────────────────────────────────────────────────────────────────

Start with the kimi acp entry point and compare its exposed capabilities with the standalone /yolo command. Reproduce the Moonshot CN high-risk refusal in Zed, then trace whether the ACP client receives an error and what happens to subsequent commands. Done means both the YOLO control and API failure behavior are observable and usable through ACP.