Feature Request: Add an option to pass initial prompt while keeping interactive mode

Current Behavior

Currently, the --prompt (or -p) option is designed for single-shot execution: CLI processes the prompt and then exits immediately without entering the interactive shell.

kimi -p "Explain this codebase"   # executes and exits

This is confirmed by the documentation:

"When using --prompt (or --command), Kimi Code CLI exits after processing the query."

Desired Behavior

It would be very useful to have an option (e.g. --prompt-interactive, --init-prompt, or a special value for --prompt) that allows users to pass an initial user message when launching the CLI, but then keep the interactive session open for follow-up questions.

For example:

# Hypothetical usage
kimi --prompt-interactive "Analyze the dependency graph of src/main.js"

# Or
kimi -p "Analyze the dependency graph of src/main.js" --interactive

After the AI responds to the initial prompt, the user can continue typing follow-up questions in the same session.

Use Cases

1. Shell aliases / wrapper scripts: Users can create shortcuts like kimi-code-review that automatically seed a specific prompt but still allow interactive refinement.
2. IDE integrations: External editors could launch Kimi with a pre-filled context (e.g. current file, selected lines) and let the developer continue the conversation.
3. Session initialization: Quickly start a session with a complex multi-line prompt without having to paste it manually after the shell starts.

Possible Implementation Ideas

• Add a new flag like --prompt-interactive TEXT or --init-prompt TEXT.
• Alternatively, make --prompt behavior depend on whether --print is present: without --print, enter interactive mode after handling the initial prompt. (However, this would be a breaking change.)
• Or support reading from a special file descriptor / here-document that gets injected as the first user message while keeping stdin open for the interactive TTY.

Workarounds Tried

• Custom Agent with system_prompt_path works for fixed context, but not for dynamic initial prompts.
• Two-step process (kimi -S session -p "..." then kimi -C) works but is cumbersome and splits the conversation into two commands.
• Piping via echo "..." | kimi does not work because the CLI detects non-TTY stdin and skips interactive mode.

Thanks for considering this!

Start with the existing CLI handling for --prompt and the non-TTY check, using the input-and-commands documentation as the behavioral reference. Decide how an initial message can be processed while preserving the interactive session and stdin; done means the initial prompt receives a response and follow-up questions remain available without breaking current single-shot behavior.