[Bug] Client crashes on large prompts: stack overflow in path regex (~900KB input), before any network request

What version of Kimi Code CLI is running?

2.0.2

Which open platform/subscription were you using?

kimi.com account (managed:kimi-code, source=oauth)

Which model were you using?

No response

What platform is your computer?

No response

What issue are you seeing?

kimi -p with a large prompt crashes the client before any network request is made. At ~900KB of input it dies with a stack overflow inside a path-detection regex; at ~950KB it dies with a bare RangeError. Both fail in under one second.

At ~900KB:

error: failed to run prompt: Invalid regular expression: /^\/([A-Za-z]:)?$/: Stack overflow
See log: ~/.kimi-code/logs/kimi-code.log

At ~950KB:

RangeError: Maximum call stack size exceeded
(Use `kimi --trace-uncaught ...` to show where the exception was thrown)

Measured threshold (macOS 15 / Darwin 25.5.0, Apple Silicon, single bundled binary at ~/.kimi-code/bin/kimi):

Prompt size	Result
100 KB	ok, 33s
200 KB	ok, 12s
400 KB	ok, 15s
600 KB	ok, 59s
800 KB	ok, 79s
850 KB	ok, 68s — last working size
900 KB	crash: Stack overflow in regex, 1s
950 KB	crash: RangeError, 0s

Correctness was verified rather than assumed: three markers were embedded at the start, middle and end of each input, and all three had to come back. (Passing the text as a file path instead proves nothing — the agent just runs tail on the file and answers from the last lines without ever loading the content.)

This is not the context window. kimi-code/k3 has a 1,048,576-token context. The same 950KB input crashes it identically and instantly, while 800KB on that same model succeeds in 32s. The server is never reached. The regex /^\/([A-Za-z]:)?$/ looks like a Windows drive-letter check; it appears to be applied to the entire prompt string rather than to a path.

Secondary bug: the log it points you to is empty. The 900KB error prints See log: ~/.kimi-code/logs/kimi-code.log. That file is being written (90 lines that day) but contains zero entries for RangeError, Stack overflow or the failure itself. Users are sent to a log that has nothing in it.

What steps can reproduce the bug?

Build a UTF-8 text file of about 900KB and pass its contents as the prompt (not as a path — a path is read lazily and never enters the context):

# ~900KB of text
head -c 921600 /usr/share/dict/words > big.txt

kimi -p "Summarize this in one line:

$(cat big.txt)"

Crashes in about one second with:

error: failed to run prompt: Invalid regular expression: /^\/([A-Za-z]:)?$/: Stack overflow

At head -c 972800 (~950KB) the message becomes RangeError: Maximum call stack size exceeded and the process exits with code 7.

Reproduced on both kimi-code/k3-256k and kimi-code/k3, so it does not depend on the model's context size. 850KB is the largest input that still works.

What is the expected behavior?

Either the prompt is processed, or the client reports clearly that the input is too large for the model's context and stops. A stack overflow inside a drive-letter regex is neither, and it gives the user nothing to act on — especially since the log the error points at contains no record of the crash.

Two concrete fixes:

1. Don't run path-detection regexes over the whole prompt string; bound the input to the length a path can plausibly have.
2. Write the crash to ~/.kimi-code/logs/kimi-code.log before exiting, since the error message already promises it is there.

Additional information

Not the same as #2650, though we are also affected by that one and have commented there with measurements. #2650 is a network-level OAuth connect timeout on parallel subagent launches. This one never reaches the network: it is a synchronous crash in the client's own input handling, reproducible in a single command, on a machine where #2650 does not occur at all.

Reproduce the failure through the kimi -p entry point with the approximately 900KB and 950KB inputs described in the issue. Trace the path-detection and error-reporting paths implicated by the regex and ~/.kimi-code/logs/kimi-code.log, then verify that large prompts no longer cause a stack overflow and that the reported failure is recorded in the log.