--resume-id is silently ignored for v2/v3 engine sessions, breaking headless multi-turn

[okajun35]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

Ubuntu 24.04.3 LTS on WSL2 (kernel 6.6.87.2-microsoft-standard-WSL2)

Kiro Version

2.19.2

Bug Description

kiro-cli chat --resume-id <ID> silently fails to resume sessions created on the v2 or v3 agent engine. Instead of restoring the conversation, it starts a brand-new session with a new ID, and reports no error or warning. Sessions created on the default (classic) path resume correctly, so the defect is specific to v2/v3 session lookup.

Feature used: headless CLI (kiro-cli chat --no-interactive) with --output-format stream-json, which was added in 2.19.2 (requested in #9066).

Intended task: use kiro-cli as a conversation engine from an orchestration tool, running a multi-turn flow (plan → implement → review → fix) as a series of separate processes. Each step captures its session ID from the stream-json output and passes it to --resume-id on the next step so context carries forward.

This is currently impossible, because the two halves are mutually exclusive:

• --output-format stream-json — the only machine-readable way to obtain a run's session ID — requires --agent-engine v2 or v3. It refuses to run on v1.
• --resume-id only resolves sessions in the classic (v1) store.

So the only path that returns a usable session ID produces IDs that cannot be resumed, and the only path whose IDs can be resumed cannot tell you what its ID is.

Impact on workflow: the silence is the damaging part. A multi-turn pipeline exits 0 on every step and produces plausible-looking output, while in reality every turn starts from an empty context. There is nothing to detect — no error, no warning, no non-zero exit. The only way to notice is to inspect the emitted sessionId and observe that it differs from the one you passed in, or to catch the agent contradicting earlier turns.

Steps to Reproduce

Run each turn in a clean, empty directory. This matters: if the reproduction script is on disk in the working directory, the agent may read the passphrase out of the file and appear to "remember" it, masking the bug.

1. Create an empty working directory and define two prompts:

   WORK=/tmp/clean-9066
   mkdir -p "$WORK" && cd "$WORK"
   P1="The passphrase is BLUE-SEVEN. Remember it. Reply OK only."
   P2="What is the passphrase? Answer in one line. Do not use any tools."

2. Turn 1 — start a headless conversation on the v2 engine and capture its session ID from the stream-json output:

   SID=$(kiro-cli chat --agent-engine v2 --output-format stream-json --trust-tools= "$P1" \
     | jq -r 'select(.type=="runFinished").data.sessionId')
   echo "$SID"

3. Turn 2 — resume that session and ask for the passphrase back:

   kiro-cli chat --agent-engine v2 --resume-id "$SID" --output-format stream-json --trust-tools= "$P2" \
     | jq -r 'select(.type=="runFinished").data | .sessionId, .finalText'

4. Observe that the sessionId printed in step 3 is different from $SID, and that finalText shows the agent has no knowledge of the passphrase. No error, warning, or non-zero exit accompanies this.

5. Repeat steps 2–4 with --agent-engine v3. Same failure (IDs are sess_-prefixed).

6. Control case — the default engine resumes correctly. Note this path cannot use stream-json, so the ID has to be scraped from --list-sessions:

   kiro-cli chat --trust-tools= "$P1"
   CSID=$(kiro-cli chat --list-sessions -f json | jq -r '.[0].sessions[0].sessionId')
   kiro-cli chat --wrap never --resume-id "$CSID" --trust-tools= \
     "Repeat the passphrase exactly. One line only."

   This answers BLUE-SEVEN.

7. Confirm that stream-json cannot be used on the engine that does resume:

   kiro-cli chat --agent-engine v1 --output-format stream-json "hi"
   

Expected Behavior

Two separate expectations, in priority order.

1. --resume-id should resolve session IDs regardless of which store holds them. Passing an ID obtained from runFinished.sessionId back into --resume-id should restore that conversation and continue it — the same behavior the classic path already has. In the reproduction above, step 3 should print the same sessionId it was given and finalText: BLUE-SEVEN.

   If cross-store lookup is undesirable, then at minimum expose a selector for it. --delete-session already accepts --session-source <v1|v2>, but that flag is hard-wired to --delete-session and cannot be combined with --resume-id (see Additional Context), so a caller has no way to say which store to search.

2. An unresolvable --resume-id must fail loudly. Silently substituting a new session is the worst possible outcome for automation: the pipeline reports success while every turn runs with no context. Expected instead:

   • a runError event on the stream-json stream, e.g.
     {"type":"runError","data":{"stage":"session","message":"session <ID> not found"}}
   • a non-zero exit code

   This is how the engine/format mismatch is already handled, and it works well:

   {"type":"runError","data":{"sessionId":null,"stage":"engine","message":"--output-format stream-json is not supported on the v1 engine. Pass --agent-engine v2 (or v3)."}}
   error: --output-format stream-json is not supported on the v1 engine. Pass --agent-engine v2 (or v3).
   

   Session-not-found should behave the same way.

Note that even if (1) is deferred, fixing (2) alone would make this survivable — the failure would at least be detectable by the calling tool.

Conversation ID

Not applicable — this is a CLI issue, not raised from the IDE, so no conversation ID was auto-populated. The relevant identifiers are the session IDs from the reproduction run:

Engine	Turn 1 session ID (passed to --resume-id)	Turn 2 session ID (actually used)
v2	8255c6fc-4bd8-460d-9e7c-794500e0805f	32a6525a-2c18-467d-8319-e3f13620d95d
v3	sess_12cdc4b5-166e-4222-8b4c-0a08b8ca4e64	sess_8a87a715-6bd6-48d8-b232-d66ddcc06539
classic (control, works)	7b7d00f2-2195-498c-a590-0ad27fc0c674	same ID — resumed correctly

Additional Context

Actual output from the reproduction

### kiro-cli 2.19.2  (Ubuntu 24.04.3 LTS on WSL2)

===== engine = v2 =====
turn 1:
  sessionId : 8255c6fc-4bd8-460d-9e7c-794500e0805f
  finalText : OK
turn 2  (--resume-id 8255c6fc-4bd8-460d-9e7c-794500e0805f):
  sessionId : 32a6525a-2c18-467d-8319-e3f13620d95d
  finalText : I don't have a passphrase in my context — nothing in this conversation or my instructions contains one.

===== engine = v3 =====
turn 1:
  sessionId : sess_12cdc4b5-166e-4222-8b4c-0a08b8ca4e64
  finalText : OK
turn 2  (--resume-id sess_12cdc4b5-166e-4222-8b4c-0a08b8ca4e64):
  sessionId : sess_8a87a715-6bd6-48d8-b232-d66ddcc06539
  finalText : I'm not sure — there's no context indicating what "passphrase" refers to. Which passphrase are you asking about?

===== control: default engine, no stream-json =====
  sessionId (via --list-sessions): 7b7d00f2-2195-498c-a590-0ad27fc0c674
turn 2  (--resume-id 7b7d00f2-...):
> BLUE-SEVEN

===== v1 engine + stream-json =====
{"type":"runError","data":{"sessionId":null,"stage":"engine","message":"--output-format stream-json is not supported on the v1 engine. Pass --agent-engine v2 (or v3)."}}
error: --output-format stream-json is not supported on the v1 engine. Pass --agent-engine v2 (or v3).

The session data is written correctly — only the lookup fails

--list-sessions -f json after the v2 run shows two independent sessions rather than one extended session, and turn 1's session is fully persisted:

{"sessionId": "32a6525a-2c18-467d-8319-e3f13620d95d", "source": "v2", "messageCount": 2, "title": "What is the passphrase? Answer in one line. Do not use any tools."}
{"sessionId": "8255c6fc-4bd8-460d-9e7c-794500e0805f", "source": "v2", "messageCount": 2, "title": "The passphrase is BLUE-SEVEN. Remember it. Reply OK only."}

By contrast, the classic control session was extended in place — messageCount went 2 → 4 → 6 over three turns on the same ID, with no duplicate session created:

{"sessionId": "7b7d00f2-2195-498c-a590-0ad27fc0c674", "source": "classic", "messageCount": 6, "title": "The passphrase is BLUE-SEVEN. Remember it. Reply OK only."}

Summary of the catch-22

Path	source in --list-sessions	Can emit its session ID?	--resume-id works?
default engine, no stream-json	classic	No	Yes
--agent-engine v2 + stream-json	v2	Yes	No
--agent-engine v3 + stream-json	v3	Yes	No

Suspected cause

A session-store resolution gap rather than a resume bug — --resume-id appears to search only the classic/v1 store while the v2/v3 engines write to their own stores. Supporting evidence:

• --delete-session has an explicit --session-source <v1|v2> selector; --resume-id has no equivalent and cannot borrow it (see below).
• chat --delete-session reports "session not found" when deleting v3 sessions #10949 reports the same class of failure from the other direction: --delete-session returning "session not found" for v3 sessions.

Also worth noting that --session-source only offers v1 and v2 — there is no v3 value — while --list-sessions reports source: "v3" for sessions created with --agent-engine v3. The store enumeration appears to have fallen behind the engine list.

Workarounds attempted

1. Point --resume-id at the right store with --session-source. Not possible — the flag is hard-wired to --delete-session:

$ kiro-cli chat --agent-engine v2 --session-source v2 \
    --resume-id 8255c6fc-4bd8-460d-9e7c-794500e0805f \
    --output-format stream-json --trust-tools= "test"
error: the following required arguments were not provided:
  --delete-session <SESSION_ID>

Usage: kiro-cli-chat chat --delete-session <SESSION_ID> --agent-engine <ENGINE> --session-source <v1|v2> --resume-id <SESSION_ID> --output-format <OUTPUT_FORMAT> --trust-tools <TOOL_NAMES> <INPUT>

2. Replay the full conversation history in the prompt on every invocation, keeping all state on the caller's side. This works, but costs tokens linearly in turn count and forfeits the benefit that #9066 was asking for. It is what I am doing now.

Related

• Expose the conversation's session ID in headless mode (--no-interactive) #9066 — the feature request this was split from. --output-format stream-json shipped in 2.19.2 and solves session-ID retrieval; this issue is about the resume half being unreachable as a result.
• chat --delete-session reports "session not found" when deleting v3 sessions #10949 — --delete-session reports "session not found" for v3 sessions. Likely the same root cause.

Environment notes

• kiro-cli 2.19.2, confirmed latest via kiro-cli update ("2.19.2 is the latest version").
• kiro-cli chat --help documents --agent-engine as defaulting to v2, but on this install --output-format stream-json fails with the v1-engine error unless --agent-engine v2 is passed explicitly, so the effective default appears to be v1. Minor, but it makes the feature look broken on first use.

[github-actions]

Thanks for opening this issue and for the thorough write-up! The silent mismatch between --resume-id and v2/v3 engine sessions — especially with no error or warning surfaced — is a really well-documented catch that clearly impacts headless multi-turn workflows. A maintainer will review this shortly. We appreciate you taking the time to trace the root cause and lay out the impact so clearly — that kind of detail really helps! 🙌

[AnilMaktala]

Thanks for raising this — and for the thorough reproduction case.

This looks like a bug where two issues compound:

1. When --agent-engine v2/v3 is explicit, the session-store routing logic might be bypassed (it appears gated on a rollout feature). The v2/v3 engine receives the session ID but seems to silently start a new session when the lookup fails.

2. The silent failure is likely the worse half: an unresolvable --resume-id should probably produce a runError event and non-zero exit, not a fresh session that reports success.

Your priority ordering makes sense: fixing (2) alone would make this survivable for automation.

Related: #10949 (--delete-session can't find v3 sessions) might share the same store-routing gap.

Marking as a bug for the team to investigate further.

[okajun35]

@AnilMaktala Thanks for picking this up. I re-ran the reproduction on kiro-cli 2.21.1 (Ubuntu 24.04.3 LTS on WSL2), and the results map onto your two hypotheses fairly cleanly: the store-routing half is fixed on both engines, and the silent-failure half — the one you called the worse of the two — is fixed on v2 but still present on v3.

Summary

Check	2.19.2 (reported)	2.21.1 (retest)
--resume-id restores a v2 session	✗ new session, different ID	✅ same ID, answers BLUE-SEVEN
--resume-id restores a v3 session	✗ new session, different ID	✅ same ID, answers BLUE-SEVEN
Unresolvable ID → runError + non-zero exit on v2	✗ silent new session	✅ exit 1 + runError
Unresolvable ID → runError + non-zero exit on v3	✗ silent new session	❌ exit 0, no runError
--delete-session on a v3 session (#10949)	✗ "session not found"	✅ deleted
--session-source usable with --resume-id	✗ hard-wired to --delete-session	✗ unchanged; values still v1|v2, no v3

The store-routing gap looks closed, and #10949 went with it

Resume now works with --agent-engine passed explicitly, on both engines. v2:

passed SID=b9b862ac-57e2-4d35-b71e-b5069ef144b6
turn 2 -> {"sessionId":"b9b862ac-57e2-4d35-b71e-b5069ef144b6","finalText":"BLUE-SEVEN"}

v3:

turn1 SID=sess_8f9163b4-9761-420f-8baf-d7700b5e36ad
turn 2 -> {"sessionId":"sess_8f9163b4-9761-420f-8baf-d7700b5e36ad","finalText":"The passphrase is BLUE-SEVEN."}

Both echo back the same sessionId they were given and carry the context forward. --delete-session also removes a v3 session now (✔ Deleted chat session sess_00000000-...), which is consistent with your guess that #10949 shared the root cause — the two moved together.

I can't tell from the outside whether the rollout gate you mentioned was flipped or the routing was reimplemented, so I'm only reporting the observable behaviour.

The silent failure is still there on v3 — and is now harder to detect than when I filed this

Passing a nonexistent session ID. v2 behaves exactly as you described it should:

$ kiro-cli chat --agent-engine v2 --resume-id 00000000-1111-2222-3333-444444444444 \
    --output-format stream-json --trust-tools= "Say HI only."
{"type":"runError","data":{"sessionId":null,"stage":"init","message":"Internal error: \"Failed to start session: Session not found: 00000000-1111-2222-3333-444444444444\""}}
error: ACP load_session failed
EXIT=1

v3 reports success and creates a session under the ID that was passed in:

$ kiro-cli chat --agent-engine v3 --resume-id sess_00000000-1111-2222-3333-444444444444 \
    --output-format stream-json --trust-tools= "Say HI only."
{"type":"runFinished","data":{"sessionId":"sess_00000000-1111-2222-3333-444444444444","status":"success","stopReason":"end_turn","finalText":"HI","finalTextTruncated":false}}
EXIT=0

$ kiro-cli chat --list-sessions -f json
{"sessionId":"sess_00000000-1111-2222-3333-444444444444","source":"v3","messageCount":null}

Two things I'd flag about this:

1. The only detection signal a caller had is gone. When I filed this, an orchestrator could catch the failure by comparing the emitted sessionId against the one it passed in — they differed. On v3 in 2.21.1 the IDs now match while the context is still empty. A stale, mistyped, or cross-machine session ID therefore yields a run that is byte-for-byte indistinguishable from a successful resume: exit 0, matching ID, no runError, plausible output. For the multi-turn pipeline case this is strictly worse to operate against than 2.19.2 was, even though the happy path is fixed.

2. The two engines now disagree on identical input. Same flags, same nonexistent ID: v2 exits 1 with runError, v3 exits 0. Anything that wants to handle this has to branch on the engine.

So the ask is narrower than the original issue: bring v3 in line with what v2 already does — runError plus a non-zero exit when --resume-id can't be resolved. Something like the shape I suggested originally:

{"type":"runError","data":{"stage":"session","message":"session <ID> not found"}}

If "create the session under the requested ID" is deliberate for v3 (remote sessions, pre-allocated IDs, something along those lines), that's workable too — but it makes --resume-id a create-or-resume flag rather than a resume flag, and --help currently doesn't say so. Either an error or a documented contract would let a caller write correct code; right now neither is available on v3.

--session-source unchanged

No longer blocking, since cross-store resume works, but the enumeration still lags the engine list:

$ kiro-cli chat --agent-engine v2 --session-source v2 --resume-id dummy ...
error: the following required arguments were not provided:
  --delete-session <SESSION_ID>

$ kiro-cli chat --help | grep -A3 session-source
      --session-source <v1|v2>
          Target only v1 or v2 store for --delete-session (default: both)
          [possible values: v1, v2]

--list-sessions reports source: "v3", so a v3 value here would still be consistent.

Minor, also improved

--agent-engine help now reads "v1", "v2" (default), or "v3" with v3 in possible values, so the "effective default appears to be v1" confusion in my original report is resolved. --agent-engine v1 + --output-format stream-json still refuses via runError, as expected.

Environment

kiro-cli 2.21.1, Ubuntu 24.04.3 LTS on WSL2 (kernel 6.6.87.2-microsoft-standard-WSL2). Every turn was run in a fresh empty directory so the agent could not read the passphrase off disk.

[okajun35]

Verified as fixed on kiro-cli 2.24.0 — thank you!

I re-ran the original reproduction in a clean, empty directory. Both expectations
from the issue now hold:

1. --resume-id resolves v2/v3 session IDs

Engine	Turn 1 session ID (passed to --resume-id)	Turn 2 session ID	finalText
v2	170f8cd1-bd1c-452a-ac63-0c1a7ac2705a	same ID	BLUE-SEVEN
v3	sess_2b242bc7-d699-43b7-81f9-2e376468809f	same ID	BLUE-SEVEN

The session is extended in place — no duplicate session is created.

2. An unresolvable --resume-id now fails loudly

$ kiro-cli chat --agent-engine v2 --resume-id 00000000-0000-0000-0000-000000000000
--output-format stream-json --trust-tools= "say hi" {"type":"runError","data":{"sessionId":null,"message":"Internal
error: "Failed to start session: Session not found: 00000000-0000-0000-0000-000000000000""}} $ echo $? 5

runError on the stream plus a non-zero exit code — exactly what automation needs.

The headless multi-turn use case from #9066 now works end to end, including
switching --agent between turns while keeping context, so I can drop the
"replay the whole history in every prompt" workaround. Closing from my side —
thanks to the team for the fix.

---

Two small leftovers, happy to file separately if you'd prefer:

• --session-source still only accepts <v1|v2>, while --list-sessions
  reports source: "v3". (Same enumeration gap noted in the original report;
  no longer blocking anything for me.)
• On the v3 engine, --output-format stream-json interleaves non-JSON log lines
  ([INFO] kas.server.starting …, [ERROR] (node:…) ExperimentalWarning: SQLite …)
  into the stream, so piping straight to jq errors out. Guarding with
  select(type=="object") works around it, but a clean stream (logs on stderr)
  would be friendlier for machine consumers.