kimi -p (non-interactive) hangs and produces zero output, while the interactive TUI works with the same credentials

Summary

kimi -p "<prompt>" hangs indefinitely and writes zero bytes to both stdout and
stderr. The interactive TUI works normally at the same time, on the same machine,
with the same credentials and the same binary.

Non-interactive mode worked reliably earlier the same day and then stopped. I have
not been able to recover it.

Environment

• macOS 26 (Darwin 25.5.0), arm64
• Kimi Code CLI 0.29.2 and 0.30.0 — reproduces on both
• Installed at ~/.kimi-code/bin/kimi
• Auth: OAuth device-code flow (kimi login)
• Model: kimi-k3 (default_model = "moonshot-ai/kimi-k3")

Reproduction

kimi -p "Reply with exactly PING"

Observed: no output, process never returns. Killed after 60–180s in repeated runs.

kimi -p "Reply with exactly PING" --output-format stream-json > out.txt 2>err.txt
# out.txt: 0 bytes
# err.txt: 0 bytes

The complete absence of output on either stream is the notable part — there is no
error, no partial stream, and no timeout from the CLI itself.

Meanwhile, in a terminal, the TUI answers the identical prompt immediately:

✨ Reply with exactly KIMI WORKING
● KIMI WORKING

What I ruled out by measurement

• Not the CLI version. Reproduces identically on 0.29.2 and 0.30.0. Non-interactive
  mode worked on 0.30.0 for ~40 minutes before it stopped, so this is not a regression
  introduced by the 0.30.0 rollout.
• Not an expired token. Reproduces with a token freshly written by kimi login
  and valid for another 10+ minutes.
• Not stdin. Same behaviour with < /dev/null.
• Not process contention. Reproduces with no other kimi process running except
  the TUI, and also reproduces when a leftover child process is killed first.
• Not the account or network. The REST API answers normally throughout:
  POST https://api.moonshot.ai/v1/chat/completions with kimi-k2.6 returns HTTP 200,
  and GET /v1/models returns the expected model list.

Possibly relevant: token lifetime

Immediately after kimi login, ~/.kimi-code/credentials/kimi-code.json contained an
expires_at only 15 minutes in the future. Non-interactive runs failed both inside
and outside that window, so a plain expiry does not explain it — but a 15-minute access
token seems short, and it may be relevant if the headless path refreshes credentials
differently from the TUI (or does not refresh them at all).

Earlier, an access token that had been expired for over 24 hours returned
401 Invalid Authentication against /v1/models, yet kimi -p at that time still
worked — which suggests the TUI/refresh path recovers from an expired access token
while the headless path's behaviour depends on something else.

Impact

-p is the only supported way to drive Kimi Code from a script, CI job, or an agent
orchestrator. With it hanging silently — no error, no exit — any automation built on it
stalls indefinitely rather than failing fast. A non-zero exit with a diagnostic on stderr
would at least make the failure actionable.

Suggested diagnostics

A verbose/debug flag for -p that logs the auth and request lifecycle would make this
self-diagnosable. Today the wire log stops at llm.request with no llm.response,
no timeout, no retry, and no provider error, which leaves nothing to act on.

Start by locating the -p non-interactive entry point and tracing the llm.request lifecycle, including credential refresh, while comparing it with the working TUI path. Reproduce the command with the stated credentials and verify that the headless path either returns output or exits with an actionable stderr diagnostic instead of hanging silently.