--starting-prompt flag to start the session with a prompt without exiting

[stebbins]

What feature would you like to see?

• Add a new flag: --starting-prompt / -s
• This allows you to pass a starting prompt when starting a new Kimi Code CLI session
• This is very similar to the existing -p / -c flags!
• However, there is an important difference: with -s, Kimi Code CLI does not exit the session after processing the prompt
• Functionally, this gives equivalent behavior as Claude Code when passing a prompt via CLI arg
• This unlocks the capability of higher-level processes to more easily "orchestrate" Kimi Code CLI sessions without building away from the design philosophy of the project (from my understanding, at least)

Additional information

No response

[stebbins]

implemented: #864

[stebbins]

@xxchan would the team be interested in this? There are a few ways it could be approached -- for example, changing behavior of existing -c/-p or allowing another flag like --interactive. Just let me know and I can adjust if needed.

[xxchan]

Hi @stebbins

This unlocks the capability of higher-level processes to more easily "orchestrate" Kimi Code CLI sessions

I just don't get why don't you use https://github.com/MoonshotAI/kimi-agent-sdk for orchestration?

[stebbins]

@xxchan one difference is that the SDK approach involves owning the Kimi Code CLI process, whereas this approach allows initiating a session without the "orchestration" process being tied to the lifespan of the Kimi Code CLI process.

I explored this because it's the mechanism gastown uses to "orchestrate" sessions.

I can work around it for gastown integration -- basically, you can use tmux send-keys to "simulate" the behavior that this flag gives you -- or just fork if y'all are uninterested in this flag.

Either way, it makes sense to use SDK or ACP when the Kimi Code CLI process should be tied to the lifespan of the orchestrating process -- but here, the intention is to launch an untethered process.

That said, I think one could get similar behavior by using SDK/ACP to create a session in some workdir, ending that process, then booting from shell with kimi --session <id>.

[xxchan]

Kimi Code CLI does not exit the session after processing the prompt

I'm curious in gastown orchestration, what happens when the agent finish the initial prompt? Do you use tmux send-keys to trigger follow-ups? 🤔

[stebbins]

The direct answer to your question is, "you can use send-keys but it depends; there are multiple options"

One of the interesting things about Gastown is that it's opinionated enough to provide orchestration structure -- but since it designs everything as "tmux sessions" -- it also gives interesting "hack" capabilities to the user which I've found to be very useful in practice, to keep agents on the rails.

This is part of the power behind design choice to center around processes in tmux:

• Other sessions can call tmux send-keys via shell command tool call so agents can orchestrate each other
• Human user can tmux attach -t <tmux session id> to "manually" orchestrate

In practice, I'll frequently use both. Initial sessions are orchestrated with some agent calling tmux send-keys. But since it's all in tmux, you can "peek" at the pane and intervene to keep the session on the rails. It is actually a really interesting and simple affordance for the user.

I'm not sure if I'm articulating this very well. I've also been considering writing up my experience, workflow examples, and design thoughts after using Gastown a lot. I can send a link if you're interested after I finish writing, hopefully within a few days

[xxchan]

I ask this because if gastown already use tmux send-keys for follow-up prompts, using it also for the initial prompt sounds reasonable.

I've also been considering writing up my experience, workflow examples, and design thoughts after using Gastown a lot. I can send a link if you're interested after I finish writing, hopefully within a few days

Would be interested!