pastilhasandClaude Opus 5
530e5880e1
Closed: - fleet/an-orchestrator-that-acts-on-every-server-at — built, and as none of the three shapes it proposed. Not a script, not a screen, not a chat capability: an agent handed a written procedure and a server list it has to read rather than one baked into it. All three verified facts in the item earned their place; two things it did not anticipate are now new items. - fleet/a-way-to-mark-a-commit-this-one-ships-so-a — built as a TAG, which the item explicitly ruled out. The owner reversed it, and the argument that changed his mind is recorded: a codeword can be written by accident, because every document about deploying contains it, so the trigger needs rules about where in a subject line it sits and a rule like that is one somebody eventually gets wrong. Opened, all from tonight and all with the evidence attached: - a deploy verifies pm2 and not that the app serves anything — the commander raised this against itself - the commander cannot finish its own host, so one machine is always a build behind - the watcher loop is rewritten by an agent every arming, so its correctness is re-rolled each time - plugins:update restarts every sidecar, so a report naming only officer understates what moved - an agent spawned by a background job is invisible in the UI while being perfectly readable - AskUserQuestion can fail to parse its own call - a commander opened from /chat loses its commander controls, because isCommander comes from the screen rather than the session Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
---
|
|
id: known-bugs/askuserquestion-can-fail-to-parse-its-own-call
|
|
title: 'AskUserQuestion can fail to parse its own call'
|
|
theme: known-bugs
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 3
|
|
---
|
|
|
|
**`AskUserQuestion` rejected a well-formed call with `InputValidationError: called with input that could
|
|
not be parsed as JSON`.** Seen 2026-08-21 in the deploy commander's first turn, on Sonnet.
|
|
|
|
The tell is in the transcript: the failed call arrives as `{"__unparsedToolInput": {"raw": "{\"questions\":
|
|
[…"}}` — the arguments reached the harness as a **string** rather than an object, and the harness reported
|
|
that as the model's fault. The retry, byte-identical in intent, went through and the question rendered
|
|
normally.
|
|
|
|
So it is recoverable and it self-corrected, which is why it is filed here rather than treated as urgent.
|
|
What makes it worth fixing anyway: this is the same tool as the stall bug fixed earlier the same day, on
|
|
the path where an agent asks a question and waits. A parse failure there burns a turn, and if it happened
|
|
on the **second** attempt too the agent would most likely give up asking and guess — which is the failure
|
|
mode the question mechanism exists to prevent.
|
|
|
|
Worth capturing the raw payload when this fires rather than only the first 200 bytes, since the message
|
|
truncates exactly where the interesting part would be.
|