/compact fails with a hard 60s timeout on longer sessions

[deltaguita]

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 26.5.1 (25F80)

Expected behaviour

Summary

/compact consistently fails on longer sessions. The failure is a hard
60-second client-side timeout, not an upstream API error.

Evidence

From ~/.kiro/logs/*/kiro.log. Every failure is exactly 60.0s after
compaction.start, matching to the millisecond:

start (UTC)	messages	result	duration
08-02 04:59:29	96	done	48.4s
08-02 15:19:27	251	failed	60.0s
08-02 16:01:39	251	failed	60.0s
08-03 07:07:12	291	failed	60.0s

The only successful run (96 messages) already took 48.4s, close to the
ceiling. Millisecond-identical intervals point to a local timer aborting
rather than an upstream failure.

Logged as:

{"timestamp":"2026-08-03T07:07:12.325Z","level":"info","message":"[KiroAgent] compaction.start {\"sessionId\":\"sess_33008086-6223-492e-9600-d3207fca5f19\",\"messages\":291,\"modelId\":\"claude-opus-5\"}"}
{"timestamp":"2026-08-03T07:08:12.325Z","level":"error","message":"[KiroAgent] Compaction failed for session sess_33008086-6223-492e-9600-d3207fca5f19: {}"}

Affected session IDs:

• sess_33008086-6223-492e-9600-d3207fca5f19 (291 messages, failed)
• sess_0647ab60-893f-46c6-ab52-be1996882839 (251 messages, failed twice)
• sess_e97ac523-6c76-4667-8ba0-f3dfbe71346e (96 messages, succeeded in 48.4s)

Problems

1. The 60s budget does not scale with message count, so longer sessions can
   never compact — which is precisely when compaction is most needed.
2. The error serializes to an empty {}, so neither the log nor the CLI
   tells the user it was a timeout. Repeated /compact attempts look like
   silent no-ops.
3. No setting can raise the limit; kiro-cli settings all exposes no
   compaction or timeout key.

Expected

Either scale the timeout with message count (or compact in chunks), or
surface a clear message such as "compaction timed out after 60s, consider
starting a new session" with the elapsed time.

Related issues (searched — not duplicates)

• Kiro CLI --v3: clipboard paste broken, context limit kills session, compaction hangs #3853 reports auto-compaction hanging under --v3: unresponsive to
  Ctrl+C, process must be killed. This is a different failure mode —
  compaction here aborts cleanly at exactly 60s and the CLI stays usable.
  That report also bundles four unrelated problems and includes no log
  evidence, so the two may still share a root cause worth cross-checking.
• The conversation history is too large to compact #2264 surfaces an explicit The conversation history is too large to compact from the Rust path crates/chat-cli/src/cli/chat/mod.rs:728
  (q 1.12.3). Different code path; this failure originates in KiroAgent
  and serializes to {}.
• Q CLI fails to compact when context is already too large #1323 is an upstream ValidationException: Input is too long. This
  one is a local timer, not an API rejection — the millisecond-identical
  60.0s intervals rule out an upstream cause.

Environment

kiro-cli 2.16.0, macOS 26.5.1 (arm64), model claude-opus-5

Actual behaviour

/compact appears to do nothing. No error is shown in the CLI, the prompt
simply returns. Running it repeatedly gives the same result, so it looks like
a silent no-op.

The log shows it is being aborted by a hard 60-second timeout. Every failure
is exactly 60.0s after compaction.start, matching to the millisecond:

start (UTC)	messages	result	duration
08-02 04:59:29	96	done	48.4s
08-02 15:19:27	251	failed	60.0s
08-02 16:01:39	251	failed	60.0s
08-03 07:07:12	291	failed	60.0s

Millisecond-identical intervals point to a local timer aborting rather than
an upstream failure. From ~/.kiro/logs/*/kiro.log:

{"timestamp":"2026-08-03T07:07:12.325Z","level":"info","message":"[KiroAgent] compaction.start {\"sessionId\":\"sess_33008086-6223-492e-9600-d3207fca5f19\",\"messages\":291,\"modelId\":\"claude-opus-5\"}"}
{"timestamp":"2026-08-03T07:08:12.325Z","level":"error","message":"[KiroAgent] Compaction failed for session sess_33008086-6223-492e-9600-d3207fca5f19: {}"}

Three things make this hard to live with:

1. The 60s budget does not scale with message count. The only successful run
   (96 messages) already took 48.4s, so anything substantially longer cannot
   finish — which is precisely when compaction is needed most.
2. The error serializes to an empty {}, so neither the log nor the CLI
   indicates a timeout. There is no way for a user to tell what went wrong.
3. No setting can raise the limit; kiro-cli settings all exposes no
   compaction or timeout key.

Affected sessions:

• sess_33008086-6223-492e-9600-d3207fca5f19 — 291 messages, failed
• sess_0647ab60-893f-46c6-ab52-be1996882839 — 251 messages, failed twice
• sess_e97ac523-6c76-4667-8ba0-f3dfbe71346e — 96 messages, succeeded (48.4s)

Related issues (searched — these are not duplicates):

• Kiro CLI --v3: clipboard paste broken, context limit kills session, compaction hangs #3853 reports auto-compaction hanging under --v3: unresponsive to
  Ctrl+C, process must be killed. Different failure mode — here compaction
  aborts cleanly at 60s and the CLI stays usable. That report also bundles
  four unrelated problems and has no log evidence, though the two may share
  a root cause worth cross-checking.
• The conversation history is too large to compact #2264 surfaces an explicit The conversation history is too large to compact from the Rust path crates/chat-cli/src/cli/chat/mod.rs:728
  (q 1.12.3). Different code path; this failure originates in KiroAgent.
• Q CLI fails to compact when context is already too large #1323 is an upstream ValidationException: Input is too long. This one is
  a local timer, not an API rejection.

Steps to reproduce

1. Start a chat session and work until the conversation reaches roughly 250+ messages. Heavy tool use gets there quickly (large API responses, log analysis, repeated file edits). 2. Run /compact. The prompt returns with no visible error and the context is unchanged. 3. Inspect ~/.kiro/logs//kiro.log: a compaction.start entry is followed by Compaction failed ... {} exactly 60.0s later.

For contrast, compaction succeeds on the same machine at ~96 messages, taking 48.4s — so the boundary is the fixed time budget, not a message-count cap.

Note on reproducing faster: what matters is the volume of content compaction has to read, not the message count alone. A session with a few very large tool results (full API responses, log dumps, large file reads) will exceed the budget at a lower message count than a session of short exchanges. In the failing sessions above, much of the bulk came from large tool outputs rather than from conversation turns.

Environment

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

[q-details]
version = "2.16.0"
hash = "ac4bc3b1417d7cec0c95266cd23b5e7feb8aa3f6"
date = "2026-07-30T22:38:17.601521Z (3d ago)"
variant = "full"

[system-info]
os = "macOS 26.5.1 (25F80)"
chip = "Apple M3"
total-cores = 8
memory = "16.00 GB"

[environment]
cwd = "/private/tmp"
cli-path = "/private/tmp"
os = "Mac"
shell-path = "/opt/homebrew/Cellar/coreutils/9.11/bin/gtimeout"
terminal = "iTerm 2"
install-method = "unknown"

[env-vars]
PATH = "/Users/USER/.pyenv/shims:/Users/USER/.nvm/versions/node/v18.20.6/bin:/Users/USER/.local/bin:/opt/homebrew/opt/mysql@8.0/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/System/Cryptexes/App/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/usr/local/MacGPG2/bin:/opt/homebrew/opt/fzf/bin"
QTERM_SESSION_ID = "c1eb03679d9444559887c199f7bd7eaf"
Q_SET_PARENT_CHECK = "1"
Q_TERM = "2.15.2"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.googlecode.iterm2"