[Bug] Agent files handoffs into the repo of a recently-read doc, not the repo that owns the work (salience anchoring; skips its own placement rule, then justifies post-hoc)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 2, 2026

What happened:
When creating a session handoff for a task spanning several internal repos, the agent saved it into the repo whose docs it had just read in full, rather than the repo that owns the actual code/deliverable. It cited "the handoffs/ folder exists" and "this repo owns the related standard doc" as justification AFTER writing, instead of running its documented placement procedure BEFORE writing. It already had the information (it had read where the code lives) but did not use it for the placement decision.

What the user said:
The user asked why that repo was chosen, and noted this happens repeatedly across sessions — handoffs landing in unrelated/arbitrary repos — and asked for a root-cause diagnosis.

Repro:
At the end of a long, multi-repo session, ask the agent to write a handoff for work that spans multiple repos. It tends to place it in whichever repo it read most recently. A project rule required reading the target repo's structure docs and placing by purpose before writing; the agent skipped that gate and applied the rule as post-hoc rationalization.

Cause:
Handoffs are written at session end when context is saturated with the last-read material, so placement is pulled by salience. With no sharp tie-breaker for multi-repo work, the agent defers to the recently-read repo and defends the already-formed choice. Part of a recurring pattern where a known procedure/evidence is bypassed at the decision step. (Secondary, same session: a reference-check used \| grep alternation, which BSD/macOS grep treats literally, yielding a false "0 matches" — an unverified-negative report caught only by reading files directly.)

View original on GitHub ↗