[Bug] Interactive TUI and non-interactive -p mode both hang indefinitely on kimi-k3 (max effort); Ctrl+C/Esc unresponsive for 10+ min; agent also exceeds instructed scope

What version of Kimi Code is running?

0.27.0

Which open platform/subscription were you using?

Kimi Platform (API key · platform.kimi.com)

Which model were you using?

moonshot-cn/kimi-k3 (max_context_size 1048576, support_efforts=["max"] only, default_effort="max")

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Kimi Code CLI hangs with no visible output for 10+ minutes in both interactive mode and non-interactive -p mode, even though the underlying Moonshot API itself responds in seconds when called directly via curl with the same key and endpoint.

This happened on two separate occasions in the same project:

1. kimi -p "hi" -m moonshot-cn/kimi-k3 — a trivial single-word prompt hung for 2+ minutes with no output, Ctrl+C had no effect, had to force-quit the terminal entirely.
2. In interactive mode, after asking for a scoped code review ("only write a report, don't modify code"), the agent silently ran a long unauthorized chain of Bash commands (git diff against an unrelated legacy directory, npx vitest run, etc.) with zero visible progress for 10+ minutes. Ctrl+C and Esc were unresponsive until the chain finished on its own.

Key findings that rule out other causes:

• curl to the same API endpoint/key returns in seconds → not a network/auth/balance issue
• ps aux shows the kimi process CPU at 10%+ and growing → not a dead/frozen process
• Context usage was only 4% (30.7k/1M) → not a context overflow issue
• kimi doctor reports config valid, CLI is already on latest version (0.27.0)

This suggests the issue is not purely "task too large", since a one-word prompt exhibited the same symptom.

What steps can reproduce the bug?

Setup:

• CLI version: 0.27.0
• Model: moonshot-cn/kimi-k3 (max_context_size 1048576, effort forced to "max", no lower option available)
• Provider: moonshot-cn, https://api.moonshot.cn/v1
• Project: mid-size React + TypeScript codebase (~1.4MB)

Repro A (trivial prompt hangs):

1. Run kimi -p "hi" -m moonshot-cn/kimi-k3
2. No output for 2+ minutes
3. Ctrl+C has no effect; requires force-quitting the terminal app

Repro B (interactive mode, scope creep + silent long chain):

1. Start kimi in project root with an existing session
2. Send a request scoped to reviewing two specific UI sections, explicitly stating "only write a report, don't modify code"
3. Agent begins a long, mostly-silent Bash tool-call sequence:
   • git log --oneline -8 -- legacy-backup/
   • ls -la src/components/ src/pages/ ...
   • diff legacy-backup/src/lib/moduleA.ts ...
   • npx vitest run src/lib/tests/moduleA...
     (legacy-backup/ is an unrelated archived directory never mentioned in the instruction; running vitest was never requested)
4. No new TUI output for 10+ minutes
5. Ctrl+C / Esc unresponsive during this window
6. Eventually Ctrl+C succeeds, showing "Interrupted by user"

Verification that the API itself is healthy:
curl -s https://api.moonshot.cn/v1/chat/completions
-H "Content-Type: application/json"
-H "Authorization: Bearer $API_KEY"
-d '{"model":"kimi-k3","messages":[{"role":"user","content":"hi"}]}'
→ returns in seconds with a valid response

What is the expected behavior?

• A trivial prompt like "hi" should return in seconds, matching the latency of a direct API call
• During long tool-call chains, the TUI should show real-time progress instead of going silent
• Ctrl+C / Esc should interrupt immediately, not queue for 10+ minutes
• The agent should respect explicit scope instructions and not autonomously diff unrelated legacy directories or run test suites that weren't requested

Additional information

Suggested fixes:

1. Add per-command progress indicators during multi-step Bash tool chains (e.g. "Running step N: command")
2. Make Ctrl+C/Esc interrupt immediately, even mid-command
3. Improve scope adherence when the user explicitly says "don't run tests" / "don't touch other directories"
4. Expose lower effort levels for kimi-k3 (currently only "max" is available via support_efforts), so users can trade speed for depth
5. Investigate why non-interactive -p mode can hang on a single-word prompt — this points to something in the request/response handling layer, not just task complexity

Full troubleshooting screenshots (command chain + final interrupt) available on request.

Start by reproducing both kimi -p "hi" -m moonshot-cn/kimi-k3 and the interactive workflow described in the issue, then compare the CLI's request/response, tool-chain progress, and interrupt paths. Trace where output and Ctrl+C/Esc handling stop responding; done means both modes return promptly, show progress during tool calls, and interrupt reliably without exceeding the requested scope.