Session permanently bricked after one 400 "high risk" rejection — no recovery path, likely false positive

Summary

After ~5 hours of normal operation, every LLM request in the session started failing with 400 The request was rejected because it was considered high risk. Once the first rejection occurred, all subsequent turns failed too (turns 17–21, five in a row), because the flagged content stays in the conversation context and is re-sent with every new request. The session became permanently unusable — there is no recovery path — and ~5 hours of work (main agent + 11 subagents) had to be abandoned.

The content being sent was innocuous: Chinese creative-writing tutorial notes (《小说构思》《情节的构思与提炼》《科幻小说的创作技巧》, etc.), pasted one per turn. This looks like a risk-control false positive, compounded by a CLI-side design gap.

Environment

• kimi-code version: 0.29.0 (native install)
• OS: macOS (darwin arm64), Terminal: Apple_Terminal, shell: zsh
• Node.js: 24.15.0
• Provider/model: kimi / k3 (kimi-code/k3), thinkingEffort=high
• Session: main agent + 11 subagents (an AgentSwarm of 5 outline-writing subagents had completed earlier); context size at failure ≈ 200k tokens (inputCacheRead: 206848)

Steps to reproduce

1. Run a long session (several hours), letting the context grow large (~200k tokens).
2. Paste long Chinese text notes one per turn (in this case, creative-writing tutorials — no sensitive content).
3. Turns 1–16 succeed. At some point one turn trips the server-side risk filter and returns 400 ... high risk.
4. From that moment on, every new turn — even a completely benign one — fails with the same 400, because the flagged content remains in the context window and is re-sent every time.

Expected behavior

• A single rejected turn should not brick the entire session. The CLI should offer a recovery path, e.g.:
  • suggest/automatically rewind or remove the offending message from context,
  • suggest /compact or starting a sub-session,
  • or at minimum print actionable guidance instead of a raw stack trace.
• Ideally the server response (or CLI) would indicate which part of the request was flagged, so the user can remove it.

Actual behavior

• Each failed turn logs attempt=1/3 and is aborted immediately (no retry — understandable for a 400, but the turn just dies):

2026-07-22T22:59:32.015Z WARN  llm request failed  turnStep=17.1 attempt=1/3 model=k3 errorName=APIStatusError errorMessage="400 The request was rejected because it was considered high risk" statusCode=400
2026-07-22T22:59:32.040Z ERROR turn failed  turnId=17
  APIStatusError: 400 The request was rejected because it was considered high risk
    at normalizeAPIStatusError$1 (.../main.cjs:1208:9)
    at convertOpenAIError$1 (.../main.cjs:53429:10)
    at KimiChatProvider.generate (.../main.cjs:53987:11)
    ...
    at async runTurn (.../main.cjs:138929:23)

• Turns 17, 18, 19, 20, 21 all fail identically within seconds of each other (22:59:32 → 23:00:00), regardless of the new user message content.
• No recovery hint is shown; the only way out is to abandon the session.

Related

• #242 reported the same error message but was a transient platform-wide incident (closed). This case is different: the rejection is persistent and content-triggered, and the report focuses on (a) the apparent false positive and (b) the missing session-recovery path after a content rejection.

Attachments

I have a full debug ZIP produced by /export-debug-zip (session wire logs, kimi-code.log, state.json). It contains private/unpublished creative content, so I'm not attaching it to this public issue — happy to email it to code@moonshot.ai referencing this issue if useful for triage. Session ID: session_1b06eb87-f71d-47b0-889c-25761daebe45.

Trace the error path from KimiChatProvider.generate through runTurn and inspect how the rejected request remains in session context. Reproduce the persistent 400 with a controlled session, then define and verify a recovery path such as removing or rewinding the offending turn, compacting, or starting a sub-session, with actionable guidance instead of only the stack trace.