VS Code 0.7.5: approval request never rendered — turn hangs silently until manual abort

What version of Kimi Code is running?

VS Code extension (0.7.5)

Which open platform/subscription were you using?

moonshot-ai

Which model were you using?

kimi-for-coding

What platform is your computer?

moonshot-ai.kimi-code-0.7.5-darwin-arm64

What issue are you seeing?

Environment: Kimi Code VS Code extension 0.7.5, bundled CLI kimi 1.49.0,
VS Code 1.136.1 (macOS arm64), macOS 26.5.2, session mode YOLO ("Ask When Needed").

A tool call that required user approval was issued, but the approval request
never appeared in the UI. The turn hung waiting for a response that could not
be given. A user message sent during the hang was rejected with:
"Session runtime error: Error: A response is already being generated for this session."
The turn only ended when manually aborted after 12.2 minutes. Approval requests
immediately before and after this event rendered and worked normally. The
extension logged no error during the hang.

Timeline from the extension output channel (times UTC):
11:06:14 streamChat id=14 started (earlier tool calls auto-approved, no prompts)
... (no bridge activity for ~12 min; no respondApproval logged for this turn)
11:18:23 Session runtime error: Error: A response is already being generated for this session.
11:18:28 abortChat -> streamChat id=14 closed, durationMs=733511 (12.2 min)
11:18:41 respondApproval ok <- retried as smaller commands; prompts render fine
11:19:03 / 11:19:31 / 11:19:55 / 11:22:10 respondApproval ok

Same pattern occurred in the previous VS window (2026-09-05): streams ran
2,504,067 ms (41.7 min) and 865,574 ms (14.4 min) before user aborts.

What steps can reproduce the bug?

1. Run a session in YOLO mode ("kimi.yoloMode": true) with the dangerous-command
   guard at default (not disabled).
2. Let the agent run a series of ordinary tool calls (Write, simple Bash) -
   these auto-approve without prompting, as expected3. The agent issues a compound Bash command the dangerous-command policy flags,
   e.g.: chmod +x <script> && bash -n <script> && plutil -lint &&
   launchctl bootstrap gui/ && sleep 2 && launchctl list | grep
3. Expected at this point: an approval card appears.
   Actual: no approval UI appears anywhere; the turn hangs indefinitely.

Session ID: 5d03d4af-799d-471f-91e5-a7728bb8bd4e
(workspace: /Users/hamstermini/Documents/KimiCode). Context usage at hang
time unknown (not visible from the UI during the hang).

Intermittent: 3 occurrences across 2 VS Code windows on the same day.
When the same operations were retried as smaller commands after the abort,
every approval request rendered and was answered successfully, so the
approval mechanism itself works.

What is the expected behavior?

• Every approval request renders an approval card in the chat view; a request
  that cannot be rendered should surface an error or time out - never hang
  silently with no UI and no log entry.
• User input sent while a turn is waiting on approval should be queued, or the
  UI should offer to interrupt the turn - not be rejected with
  "A response is already being generated for this session."
• A turn waiting on approval should be visually distinguishable from a turn that is actively working (e.g. a "waiting for approval" indicator), so a
  silent render failure is noticeable.

Additional information

No response

Contribution

• I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)

Start by reproducing the hang in the VS Code extension with kimi.yoloMode enabled and the default dangerous-command guard, then trace the streamChat, approval-card, bridge, and respondApproval events in the extension output channel. Compare the failing compound Bash request with the smaller commands that render correctly. Done means every approval request renders or reports a timeout/error, and the waiting turn is visible or interruptible.