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

### Checks

- [x] I have searched [github.com/aws/amazon-q-developer-cli/issues](https://github.com/aws/amazon-q-developer-cli/issues?q=) and there are no duplicates of my issue
- [x] I have run `q doctor` in the affected terminal session
- [x] I have run `q restart` and replicated the issue again

### 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](https://github.com/user-attachments/files/30915765/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//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

```yaml

[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"
```

Start with a fresh `kiro-cli chat --v3` session and reproduce the cancelled approval flow while tracking `q-developer-converse` history counts. Inspect the `ACP ToolApproval`, `agent-controller`, and `AgentIterator` paths named in the logs. Done means cancelled approvals no longer trigger false parallel execution or restore an older conversation snapshot.

Written by the indexing model from the issue text.