Feature Request: Support an initial user message when starting the interactive TUI

What feature would you like to see?

I would like Kimi Code to support starting or resuming its native interactive TUI with an initial model-facing user message.

The intended behavior is:

1. Start or resume an interactive Kimi Code session.
2. Submit the supplied text exactly once as a user message after the session is ready.
3. Keep the native TUI open for follow-up conversation.

The supplied text should be treated as message data, not as synthetic input to the TUI command editor.

For example, initial messages beginning with !, /auto, or /permission should be delivered literally to the model. They should not execute a shell command, invoke a slash command, or change the permission mode.

The initial message should also:

• support multiline text and Unicode;
• remain pending until authentication and session initialization have completed;
• be consumed only once, including across login, logout, reload, or session reinitialization;
• use the same permission and approval behavior as a message submitted normally in the interactive TUI;
• make the TUI available while the initial turn is running, so the user can approve, reject, interrupt, or steer it normally;
• work when starting a new session and, if supported, when resuming a specific session.

This request is about the capability and its behavioral contract. I am not proposing a particular CLI option name or syntax here.

Additional information

A similar capability was previously requested for the Python implementation:

• https://github.com/MoonshotAI/kimi-cli/issues/2240

A TypeScript implementation was also proposed:

• https://github.com/MoonshotAI/kimi-code/pull/23

Those discussions used --prompt-interactive (-P) as one possible interface. This issue references that work as prior exploration rather than proposing that specific option name.

PR #23 was closed with a request to discuss new features in an issue before submitting an implementation. This issue is intended to provide that discussion point in the current kimi-code repository.

The current alternatives have different behavior:

1. kimi -p "<prompt>" is not equivalent to an initial message in an interactive session. It runs the entire first turn headlessly and only allows the session to be resumed in the TUI after that turn has completed. Prompt mode also currently uses automatic permission handling (see #2099), so the user cannot approve, reject, interrupt, or steer the first turn through the TUI.

2. Writing text into the TUI through a PTY simulates user keystrokes. This mixes message data with TUI control syntax. Text beginning with ! can enter shell mode, while values such as /auto or /permission can be interpreted as commands.

3. SDK and ACP integrations are useful when an application provides or owns the frontend, but they do not cover the case where a launcher wants to start the native Kimi TUI, provide an initial handoff message, and then leave the user in that interactive session.

Other agent CLIs support the underlying capability of launching an interactive session with an initial message. Providing an explicit model-facing input path in Kimi Code would make terminal and session-manager integrations simpler and avoid injecting synthetic keystrokes into the TUI.

No implementation files or tests are named. Start by tracing the CLI's interactive TUI startup, session initialization, and prompt-mode paths, then compare them with the PTY, SDK, and ACP alternatives described here. Done means an agreed interface and behavior that submits one literal initial message, preserves normal TUI controls and permissions, and works across initialization and supported session-resume flows.