execute_bash command-channel integrity failure: stdout/receipt marker mismatch

首先定位 execute_bash 入口点，以及命令执行涉及的 stdout/receipt 处理。使用文档中记录的 A-D unique-marker sequence，在重复执行的命令或会话中重现该问题，然后验证每个 stdout 标记、receipt 文件和命令结果是否始终保持一致的配对关系。

Checks

• I have searched github.com/aws/amazon-q-developer-cli/issues and there are no duplicates of my issue
• I have run q doctor in the affected terminal session
• I have run q restart and replicated the issue again

Operating system

macOS 12.7.6 (21H1320)

Expected behaviour

execute_bash should preserve command/result pairing. The stdout, exit code, and any receipt file read immediately afterward should correspond to the command just issued, not a previous command in the session.

Actual behaviour

Subject: execute_bash / command receipt channel mismatch causing unsafe mutation state

I’m seeing recurring reliability failures in Kiro execute_bash where command output markers and receipt files do not consistently correspond to the command just issued.

Impact:

• Kiro cannot safely perform git add/git commit or other mutation commands.
• We have had to stop all mutation workflows when canary checks fail.
• Read-only commands can sometimes be verified through file-backed receipts, but mutation workflows are not trustworthy when the channel mismatch appears.

Observed behavior:

• A command is issued with a unique marker.
• The next observed stdout/receipt sometimes shows a marker from a prior command.
• File-backed receipt verification has also shown inconsistent command/result pairing.
• This happens intermittently across sessions, not just one command.
• Because of this, Kiro cannot reliably prove:
  command issued = command whose output was read
  stdout marker = correct receipt
  receipt file = current command result

Example consequence:
During Git admission, Kiro correctly stopped before staging/committing because canary C failed. Manual Terminal commit by the user was required instead.

Current workaround:

• Kiro performs read-only audits and prepares exact commands.
• User runs Git mutations manually in Terminal.
• Kiro performs read-only reconciliation afterward.
• We treat Kiro execute_bash as READ_ONLY_TRUSTED_WITH_RECEIPTS but NOT trusted for mutation when canaries fail.

Requested help:
Please investigate execute_bash stdout/receipt routing/session isolation. This appears to be a command-channel integrity bug, not a normal shell error.

Steps to reproduce

The issue is intermittent, so I cannot reproduce it on every run. I can reproduce/observe it by running a sequence of execute_bash commands that each write a unique marker and receipt file, then immediately asking Kiro to read the corresponding receipt.

Reproduction pattern:

1. In a Kiro chat session, ask the agent to run shell commands one at a time using unique markers, for example:

   • command A writes output to /tmp/kiro_canary_A.txt and echoes CANARY_A_MARKER
   • command B writes output to /tmp/kiro_canary_B.txt and echoes CANARY_B_MARKER
   • command C writes output to /tmp/kiro_canary_C.txt and echoes CANARY_C_MARKER
   • command D writes output to /tmp/kiro_canary_D.txt and echoes CANARY_D_MARKER

2. After each command, have the agent read the expected receipt file and compare:

   • the stdout marker shown by execute_bash
   • the marker written inside the receipt file
   • the expected command/receipt pairing

3. Repeat across several commands or sessions.

Expected result:
Each command’s stdout marker and receipt file should match the command just issued.

Actual intermittent result:
The next observed stdout or receipt sometimes contains a marker from a prior command, or the agent observes a receipt/marker that does not correspond to the command it just issued.

Example observed mismatch:
After later commands, Kiro displayed a prior marker such as RECON7B_MARKER/H_MARKER/I_MARKER instead of the marker for the current command. In another session, the canary sequence failed at Canary C, so Kiro correctly stopped before performing git add/git commit.

Important note:
A later fresh session ran canaries A/B/C/D successfully, so the issue is not constant. The problem is intermittent command-channel integrity, not a deterministic shell command failure.

Environment

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

[q-details]
version = "2.18.1"
hash = "74b78bb5a369788e393b06654b2b213d937a41d2"
date = "2026-08-13T23:20:56.707604Z (3d ago)"
variant = "full"

[system-info]
os = "macOS 12.7.6 (21H1320)"
chip = "Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz"
total-cores = 4
memory = "16.00 GB"

[environment]
cwd = "/Users/USER"
cli-path = "/Users/USER"
os = "Mac"
shell-path = "/bin/zsh"
shell-version = "5.8"
terminal = "macOS"
install-method = "unknown"

[env-vars]
PATH = "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/USER/.local/bin"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.apple.Terminal"