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.
- Start a fresh session (
kiro-cli chat --v3).
- Prompt something that makes the agent call a tool needing approval, e.g. any
run_command that evaluates to policy effect "ask".
- When the approval prompt appears, cancel it. Do not approve or deny.
- Send any new prompt.
[agent-controller] Parallel execution detected is logged even though nothing else is running, followed by [AgentIterator] Parallel invoking agent.
- 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"
Checks
q doctorin the affected terminal sessionq restartand replicated the issue againOperating 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 messagesTracking M across 212 requests in one fresh session:
Correlation over that session:
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:
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 sameParallel execution detectedsignature 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.
kiro-cli chat --v3).run_commandthat evaluates to policy effect "ask".[agent-controller] Parallel execution detectedis logged even though nothing else is running, followed by[AgentIterator] Parallel invoking agent.[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:
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