First identify what the agent was supposed to work against. A Git commit has a tree of versioned files, while a working tree can contain newer and uncommitted edits. Git's data model distinguishes those states. If retrieval says “current repository” but combines an index from commit A with files at commit B plus uncommitted changes, that is not a consistent snapshot. More context can make the contradiction more convincing rather than resolving it.

I would trace each piece of evidence: repository ID, commit or tree ID, working-tree revision if applicable, index build revision, path and content hash. Find when the index last processed the changed API and whether its references now point to different line numbers. The agent should not silently treat an old symbol summary as authoritative after seeing a new test. It can flag a revision mismatch, inspect the actual source, and refresh or bypass stale derived context. A generated embedding or graph edge is an acceleration structure, not a source of truth.

For a single-agent task, one choice is a pinned commit plus a private worktree. The agent reads and patches that snapshot, then tests and merges against the current target with conflict detection. If the requirement is to incorporate live uncommitted work, take an explicit snapshot or maintain revisioned overlays, and tell the agent which paths may have changed. At the edit boundary, compare expected file hashes or commit ancestry before applying a patch. At the merge boundary, rerun relevant tests against the actual merged tree. One cannot guarantee that a long run sees a moving repository atomically by checking HEAD once at the beginning.

Should every index update block the agent? No. A stale index entry for an unrelated path may not matter. Track dependencies and invalidate the affected symbol or file context, then refetch on demand. But if the old API signature is central to the patch, fail the read as stale or mark the response so the agent must inspect source. Test a race where the API changes between retrieval and edit, and another where tests change after the patch but before merge. The important property is provenance that survives into the decision. Several coding agents edit one repository. What can you safely merge? asks how several agents' edits can merge. This question asks whether even one agent's inputs described the same repository.