Expose the conversation's session ID in headless mode (--no-interactive)

[okajun35]

Kiro Product

CLI

Feature Description

Problem / background

I want to resume, verify, and audit conversations that were run with
kiro-cli chat --no-interactive (headless). To do that I need to know which session a
given run corresponds to, but there is no way to obtain that session ID in headless mode.

Concrete needs:

• Resume: continue a previous headless run. Resuming requires the session ID.
• Traceability / audit: review and trace conversations executed in CI or automation
  later on, by linking a run to its session.
• External tool integration: when embedding headless as a conversation engine, manage
  each run's session from the caller side.

Constraints confirmed in kiro-cli 2.5.1:

1. On --no-interactive, the session ID is not printed to stdout in a machine-readable
   form. Interactive mode has /session-id and an on-exit resume hint, but neither is
   emitted in headless mode.
2. --resume-id <a brand-new ID> does not create a new session (only existing IDs can be
   resumed).
3. As a workaround, you can run --list-sessions right after a turn (newest first; the
   ~10s lag from 2.2.2 is gone in 2.5.1) to grab the real ID. But (a) it is printed to
   stderr, and (b) if multiple conversations are started concurrently in the same
   directory, they all grab the same "latest" ID and get mixed up.

Since passing a real ID to --resume-id resumes correctly regardless of cwd (confirmed),
any reliable, immediate way to obtain a run's session ID would satisfy all of the above —
including multi-turn conversations under parallelism.

Desired behavior

Any one of the following would be sufficient:

• --print-session-id: print the session ID used for the run to stdout.
• --output-format json (applied to chat, not just --list-models): emit the response
  body, session ID, credits used, etc. as JSON.

  { "sessionId": "e0b90fad-...", "content": "...", "credits": 0.11 }

• Allow --resume-id <arbitrary ID> to create a new session under the given ID. If the
  caller can mint the ID, retrieval is unnecessary and parallel use is solved naturally.

Interactive mode already implements /session-id, so emitting the same value in headless
mode is likely low-cost.

Use Case

Example 1: Resume and audit a headless conversation (basic)

# First run: start a headless conversation and capture the session ID
SID=$(kiro-cli chat --no-interactive --print-session-id "Propose a project structure" | extract_id)

# Later / another job: resume the same conversation
kiro-cli chat --no-interactive --resume-id "$SID" "Implement the previous proposal"

With an immediately available session ID, conversations run in CI/CD or batch jobs can be
tracked and resumed per session, and reviewed afterward (validation / audit).

Example 2: AI agent orchestration

An orchestration tool invokes kiro-cli as a conversation engine and runs a multi-turn
flow (plan → implement → review → fix) while preserving context. It also runs parallel
reviews (multiple reviewers started concurrently).

• Each step is a separate process, so the session ID must be returned immediately per call.
• Especially when starting multiple conversations in parallel in the same directory,
  --list-sessions "latest" cannot disambiguate them, so each call needs to reliably get
  its own session ID.

Additional Context

• Test environment: kiro-cli 2.5.1 (Linux / WSL2).
• Passing a real ID to --resume-id resumes regardless of cwd (confirmed).
• --list-sessions lists newest first and is near-instant, but it prints to stderr and
  cannot disambiguate concurrent new conversations.
• ACP mode (kiro-cli acp) exposes explicit session/new / session/load with session
  IDs, but having an equivalent ID-retrieval mechanism in the lightweight headless CLI
  would make automation integration much easier.

[github-actions]

🤖 Potential Duplicate Detected

This issue appears to be similar to:

• #8477: feat: add non-interactive kiro-cli usage command for IDE/tooling integration (85% similar)
• #7788: Display session ID and resume command on session exit (85% similar)

What happens next?

• ⏰ This issue will be automatically closed in 3 days
• 🏷️ If this is not a duplicate, you can prevent automatic closure by adding a comment or reacting with 👎 to this message.
• 💬 Comment on the original issue if you have additional information

Why is this marked as duplicate?
Both issues request machine-readable output from kiro-cli in headless/non-interactive mode for tooling integration. Issue #8477 specifically requests JSON output for usage data, while the new issue requests session ID exposure in JSON format or other machine-readable ways for the same integration purposes.

[okajun35]

Thanks for the pointer. I agree this is related to #7788, but I don't think it is fully covered by it.

#7788 is mainly about the interactive exit flow: after a human user exits a chat session, Kiro should print the session ID / resume command.

This issue is about headless mode (--no-interactive), where there is currently no reliable way for a caller to obtain the session ID of the run at all. That makes resumable, multi-turn automation impossible to implement deterministically.

What I verified with kiro-cli 2.5.1

1. --no-interactive prints neither the session ID nor a resume hint to stdout/stderr. /session-id and the on-exit hint are interactive-only.
2. --resume-id <a-brand-new-id> does not create a session under that ID. It only works for already-existing session IDs.
3. The only workaround is to run --list-sessions immediately after a turn and scrape the newest UUID. But the output is printed to stderr, and more importantly, it cannot disambiguate concurrent runs.

Why this is not just an interactive UX issue

When two new conversations are started in the same directory at the same time, both can grab the same "latest" session from --list-sessions, causing their contexts to merge.

Reproduced with two parallel headless calls:

Two fresh conversations started concurrently in the same cwd

A.sid: 87c3433c-...
B.sid: 87c3433c-...
separated: false

A ("frontend") recalls: "backend"

So the current workaround is race-prone. Any orchestration tool that runs parallel agents, for example frontend and backend agents at the same time, can non-deterministically corrupt the conversation state.

Suggested extension

In addition to the interactive on-exit hint requested in #7788, please expose the session ID in headless mode through one of these:

• --print-session-id — print the run's session ID to stdout.
• --output-format json for chat, for example: { "sessionId": "...", "content": "...", "credits": 0.11 }
• Allow --resume-id <arbitrary-id> to create a new session under a caller-supplied ID.

Any of these would make headless multi-turn and parallel-agent automation deterministic. Since interactive mode already has /session-id, this feels like exposing the same underlying value to non-interactive callers rather than a separate feature.

[github-actions]

Thank you for your feedback! 🙏

The duplicate label has been removed and this issue has been sent back for maintainer review.

A maintainer will review this issue shortly.

[AnilMaktala]

Thanks for raising this! We've marked it as a feature request for the team to evaluate. We'll update this issue if it gets prioritized.