`-p/--prompt` has no non-argv input path: piped stdin is ignored and there is no `--prompt-file`

What feature would you like to see?

Summary

kimi -p accepts the prompt only as a command-line argument. Piped stdin is read by
nothing in the prompt path, and there is no --prompt-file. On Windows this makes the
OS command-line length cap a hard ceiling with no way around it: prompts above roughly
32 KB (git-bash) or 8 KB (cmd.exe) cannot be passed at all.

claude -p (stdin) and codex exec (stdin, appended as a <stdin> block) both have an
escape hatch here; kimi-code currently does not.

Reproduction

Version: 0.38.0, Windows 11.

1. Piped stdin is ignored

$ echo "The passphrase is PANDA-4417" | kimi -p "If you see a passphrase in the input, repeat it. Otherwise answer NONE." -m kimi-code/kimi-for-coding-highspeed
NONE

2. Large prompts cannot be passed

A 60 KB prompt (UTF-8) never reaches the process:

$ kimi -p "$(cat prompt60.txt)" -m kimi-code/k3
bash: /c/Users/<user>/.kimi-code/bin/kimi.exe: Argument list too long

The cap is the OS command line, not kimi — the same argv length fails identically for
python.exe. Measured on this machine:

Shell	Limit	Chinese text (UTF-8, 3 bytes/char)
git-bash	~32,700 bytes (32,600 ok / 32,700 fails)	~10,000 characters
cmd.exe	~8,191 characters (8,100 fails)	~2,700 characters

So on cmd.exe a prompt longer than about 2,700 Chinese characters is unusable.

Why the workaround is not equivalent

The only alternative today is to put the material in a file and ask the model to read it
itself. That turns a single-turn request into a multi-turn tool loop, and every turn
resends the accumulated context. Same 60 KB material, same question, same machine:

How the material is passed	Elapsed
claude -p via stdin (--task-file)	6.8 s, 1 turn
codex exec < file	31.6 s
kimi -p "read draft.md, review it" (model reads it itself)	58.7 s

All three returned the correct answer (a marker planted on the last line of the material
verified that it arrived in full), so this is a cost difference, not a correctness one.

Suggested change

apps/kimi-code/src/utils/process/stdin.ts already exports readStdinText(); it is not
used by the prompt path. In apps/kimi-code/src/cli/commands.ts the option is declared at
-p, --prompt <prompt> (~line 61) and mapped to opts.prompt (~line 174).

Two options, either would solve it:

1. Read piped stdin in prompt mode. When process.stdin.isTTY is false, read stdin and
   either use it as the prompt (if -p is absent) or append it to the -p value.
   codex exec uses the append form and documents it in --help.
2. Add --prompt-file <path>, mutually exclusive with -p.

Option 1 matches what the other two CLIs do, so scripts can move between them unchanged.

One caveat worth designing around, learned from codex exec: once stdin is consumed, a
non-TTY stdin that never closes (a background pipe) makes the process wait forever. Guard
with isTTY and document that background callers must give stdin EOF.

Additional information

Environment

• kimi-code 0.38.0, Windows 11
• Also relevant on Linux/macOS for the stdin part; the length cap itself is Windows-only
  (argv there is ~2 MB)

Duplicate check

Searched open issues for stdin, prompt-file, and Argument list too long — nothing
covering this. Closest matches are about hook stdin payloads and TUI escape sequences.

Start with apps/kimi-code/src/cli/commands.ts, where -p/--prompt is declared and mapped to opts.prompt, then inspect apps/kimi-code/src/utils/process/stdin.ts and its readStdinText() export. Decide which proposed non-argv input behavior to implement, account for non-TTY stdin and EOF, and document the chosen behavior in --help. Done means large or piped prompts reach prompt mode without relying on command-line length limits.