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>
1.3 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| known-bugs/askuserquestion-can-fail-to-parse-its-own-call | AskUserQuestion can fail to parse its own call | known-bugs | open | 2026-08-21 | stated | 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.