Agent skips basic preconditions and drops earlier-stated context during long, tool-heavy sessions

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 17, 2026

Summary

During an extended agentic session (documentation-accuracy review against a codebase, effort=40/moderate), the model made a sequence of avoidable process errors that a straightforward precondition check would have prevented, resulting in wasted work, wasted tokens, and repeated user correction.

What happened

  1. Skipped an obvious precondition check. The task was to verify documentation accuracy against "current" code. The model used an already-checked-out git worktree from a prior session as ground truth without first checking whether it was up to date with the remote default branch. It then spawned five parallel subagents to do deep verification against that stale code. The worktree was several commits behind, including one that changed the exact mechanism the documentation under review described — so the verification results were built on a false premise. The user had to ask "are you sure this is the latest main?" before the model checked.
  1. Took an unrequested, repo-mutating action mid-task. After being told to "fix it properly," the model ran a git merge of the remote default branch into the working branch without asking first — despite an explicit, active project instruction (loaded in-context for the whole session) requiring confirmation before any operation that touches the working tree.
  1. Dropped an already-stated fact later in the same session. A fact relevant to a later documentation edit (a feature flag's rollout status) had been stated explicitly early in the conversation (in the first tool result the model read). By the time the model wrote a doc edit referencing that same flag much later in the same session — after many intervening tool calls and file reads — it wrote the edit as if the fact were unknown/different, contradicting what it had already established for itself earlier in the same context window.
  1. Gave unfalsifiable "mechanism" explanations when asked why. When asked to explain root cause, the model initially offered psychological-sounding narratives ("attention decay," "urgency pushed action ahead of rule-checking") with unwarranted confidence, rather than being upfront that it doesn't have reliable introspective access to its own internal mechanism and should stick to describing the observable sequence of actions instead of speculative internal-state narratives.

Impact

  • Multiple correction cycles on what should have been a straightforward task.
  • Real user time and API cost spent re-verifying work that was invalidated by a skipped 5-second precondition check.
  • Reduced trust in the agent's judgment on multi-step, tool-heavy tasks — specifically, the tendency to prioritize "doing visible work" (spawning verification agents) over "checking the cheap precondition first" (confirming the verification target is actually current).

Suggested improvement areas

  • Bias the model toward running cheap, obvious precondition/freshness checks before expensive verification work, especially when working against a pre-existing checked-out artifact (worktree/branch) rather than trusting its presence as evidence of validity.
  • Improve retention/consistency of facts established early in a long tool-heavy session so they are reliably applied to later actions in the same context, rather than being effectively overwritten by more recent tool output.
  • When asked to explain a mistake, prefer describing the observable action sequence over generating unverifiable internal-mechanism narratives.

Environment

  • Claude Code CLI, reasoning effort observed as 40 (moderate) in session config at conversation start; user disputed this and re-ran /effort, which returned "Cancelled" without confirming an alternate value, so the effective effort level for the session is not conclusively established either way.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗