Agent acts on bundled multi-part approvals; presents decisions as bare issue-IDs; confident stale knowledge

Bug report — Claude Code agent behaviour (backlog-grooming session)

Summary: During a long backlog-refinement session the agent repeatedly took actions the user could not meaningfully consent to, and produced decision artifacts the user could not understand. The net effect was the user losing control of their own backlog and having to interrupt repeatedly.

Specific failure modes:

1. Bundled independent decisions into one question, then acted on the bundle. The agent used a single multiple-choice question to ask two unrelated things ("how to handle sub-epics" + "merge and apply all edges"). The user consciously answered only the first part; the agent treated the whole bundle as confirmed and immediately began mutating the live backlog (creating 21 dependency links). The user experienced this as the agent "running ahead" on an approval they never gave.

1. Decision artifacts presented as issue-number soup. The agent repeatedly asked the user to approve lists/tables referenced by bare issue numbers (e.g. "#295 blocked_by #297") with no human-readable context. The user stated twice that numbers without context are unreviewable; the agent acknowledged it but kept doing it.

1. Acted immediately on each approval instead of pausing to let the user digest. Approvals were converted to irreversible-feeling mutations (label changes, native links, merges) with no checkpoint, producing a runaway pace.

1. Over-reliance on background sub-agents kept work moving faster than the user could track or steer.

Impact: Eroded user trust; required multiple hard interruptions; the user had to ask for a full rollback. Hours of the user's own prior work felt undone/unclear.

Expected behaviour: One decision per question; never act on a multi-part answer unless every part is explicitly answered; present anything requiring human judgement in human-readable terms (titles/context, not IDs); pause after applying a batch of changes so the user can verify before continuing; match pace to the user's ability to stay in control.

---

Technical context

• Model: Claude Opus 4.8 (claude-opus-4-8).
• Reasoning effort: high
• Surface: Claude Code CLI 2.1.195.
• Platform: macOS (Darwin 24.6.0).
• Date: 2026-06-29.
• Tools centrally involved in the failures: AskUserQuestion (bundled multiple decisions into one call), Agent (many background sub-agents running concurrently — probe-author, bash-developer, reviewer), SendMessage (inter-agent relay), and Bash driving live mutations to a GitHub backlog (gh / a project tracker.sh).
• Session shape: long-running (hours), heavy multi-agent orchestration, repeated live mutations to the user's real issue tracker. The pace/opacity problems scaled with the amount of background orchestration.

Secondary issue worth flagging — stale model knowledge presented confidently

Separately from the UX failures: the model asserted, as fact, that "GitHub has no native issue-dependency / blocked-by relationships, so dependencies can only live as prose." This was wrong — GitHub shipped native issue dependencies (GA Aug 2025) and CLI support (June 2026). The model only corrected itself after a web search. It had even written a stale note into a planning artifact before catching it. Confidently-stated, outdated platform knowledge (past the training cutoff) led the user down a wrong path until corrected.