Skip to content

Conversation history reverts to a stale snapshot when"Parallel execution detected" fires after a cancelled tool approval #3884

Description

@Bo3gyX19

Checks

Operating system

Linux 5.15.0-181-generic - Ubuntu 22.04.5 LTS

Expected behaviour

Each turn should be sent to the model with the full conversation history for that
session, so the agent remembers its own previous reply and the decisions already made
in the conversation.

When history genuinely does not fit the context window, older turns should be dropped
or compacted, and the most recent turns should be preserved.

Actual behaviour

The agent silently loses recent turns and re-asks questions that were already answered. Requests are rebuilt from a stale conversation snapshot, discarding every turn after that point. The agent then repeats the same question rather than degrading gradually, because it reverts to the identical earlier state each time.

This is not compaction or a context limit. It happens on fresh sessions with roughly 7% of the context window in use, and no compaction or summarization events appear anywhere in the logs.

kiro-cli logs the history size on every request:
[q-developer-converse] Request payload: N chars, M history messages

Tracking M across 212 requests in one fresh session:

17:31:44  chars=230722  history= 90
17:32:41  chars=225041  history= 86   <- dropped, Parallel warning same second
17:57:59  chars=292604  history=104
18:04:03  chars=225116  history= 86   <- dropped, Parallel warning same second
18:34:04  chars=250905  history=118
18:35:14  chars=227671  history= 92   <- dropped, Parallel warning same second

Correlation over that session:

model requests logged            212
"Parallel execution detected"     50
history drops                     26
  at a Parallel timestamp         24   (other 2 = invoke_subagent, expected)
Parallel warnings producing a
  floor-history request           49 / 50

Every drop returns to nearly the identical payload size, so the same prefix is kept and the newest turns are what get discarded.

No concurrency is actually present. The controller reports itself idle 34 seconds before declaring a parallel execution on a brand new prompt:

18:14:46  [ACP ToolApproval] Got response: {"outcome":"cancelled"}
18:14:46  [agent-controller] Progressing model queue {"activeExecution":false,"queueSize":0}
18:15:20  [KiroAgent] ACP session/prompt
18:15:20  [agent-controller] Parallel execution detected
18:15:20  [AgentIterator] Parallel invoking agent

This suggests a cancelled approval leaves the execution registered as active. The condition is sticky: 13 cancels produced 50 warnings, so once tripped, later turns keep reverting to the same snapshot.

I first hit this in a session that had been running a long time, closed everything, and started a fresh session with kiro-cli chat --v3. The same behaviour appeared almost immediately in the new session, so it is not related to session age or size. The same Parallel execution detected signature also appears 20 times in Kiro IDE 1.0.288 logs for a separate session, though the IDE log does not record request payload sizes.

Impact: the agent forgets its own previous reply, re-asks settled decisions, repeats completed plan steps, and consumes credits re-treading resolved ground.

Full per-request history table, correlation counts, and log excerpts are in the

kiro-history-truncation-evidence.txt

attached kiro-history-truncation-evidence.txt (paths redacted).

Steps to reproduce

Yes, reproducible.

  1. Start a fresh session (kiro-cli chat --v3).
  2. Prompt something that makes the agent call a tool needing approval, e.g. any run_command that evaluates to policy effect "ask".
  3. When the approval prompt appears, cancel it. Do not approve or deny.
  4. Send any new prompt.
  5. [agent-controller] Parallel execution detected is logged even though nothing else is running, followed by [AgentIterator] Parallel invoking agent.
  6. The next [q-developer-converse] Request payload: line shows the history message count collapsed to an earlier value. Every later turn keeps reverting to that same value.

To observe it directly:

grep -o 'Request payload: [0-9]* chars, [0-9]* history messages' \
  ~/.kiro/logs/<newest>/kiro.log

The count should climb by 2 per turn. Each reset to a lower number is the bug, and each one lines up to the second with a "Parallel execution detected" line in the same log.

Environment

<This will be visible to anyone. Do not include personal or sensitive information>

[q-details]
version = "2.16.2"
hash = "b43b3506cf009fadc655eb9f189dcc2b849db53d"
date = "2026-08-06T04:47:01.105053Z (5d ago)"
variant = "minimal"

[system-info]
chip = "AMD EPYC 9354 32-Core Processor"
total-cores = 6
memory = "31.34 GB"

[system-info.os.linux]
kernel_version = "5.15.0-181-generic"
id = "ubuntu"
name = "Ubuntu"
pretty_name = "Ubuntu 22.04.5 LTS"
version_id = "22.04"
version = "22.04.5 LTS (Jammy Jellyfish)"

[environment]
cwd = "/home/USER/local-git-storage"
cli-path = "/home/USER/local-git-storage"
os = "Linux"
shell-path = "/usr/bin/zsh"
shell-version = "5.8"
install-method = "unknown"
in-ssh = true

[env-vars]
PATH = "/home/USER/.kiro-server/bin/ec90738d3f0da2389adcb94a6661b5abf1fc20e8/bin/remote-cli:/env/seligic/bin:/home/USER/.afs/0/ibin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/USER/.dotnet/tools:/opt/puppetlabs/bin:/home/USER/.local/bin:/usr/sbin:/sbin:/app/arc/0/bin:/snap/bin"
Q_SET_PARENT_CHECK = "1"
SHELL = "/bin/sh"
TERM = "xterm-256color"
XDG_SESSION_TYPE = "tty"
ZDOTDIR = "/home/USER"

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions