Agent executes against a different target than the one explicitly named
Summary
Given an explicit identifier for what to work on, the model works on a different one.
Concrete instances
Wrong ticket. In a separate session the user asked the agent to fix one specific numbered ticket. It began working on a different numbered ticket entirely.
Wrong pull request. Mid-thread on one subsystem, with a blocked review of that subsystem outstanding, the user said "review the pull requests". The model selected an unrelated change, fetched its diff and discussion, verified it and delivered a full verdict on it. This was the third instance in one session of answering a question about the blocked work with something else.
Data fetched instead of the question answered. Asked what work remained, the model queried the version-control host for a listing of all open pull requests in the user's own repository and printed thirteen lines of it. The answer was in the session's own history: one review it had started and never finished.
Why this matters
An explicit identifier is the least ambiguous instruction a user can give. When it is not honoured, no instruction can be trusted to scope work, and the user must supervise the target selection of every task.
Expected
Explicit identifiers bind. Resolve ambiguous scope from the active thread rather than toward the widest reading, and where the interpretation materially changes what gets done, ask in one line rather than spending a turn on unwanted work. Distinguish questions about the model's own state from questions about the world.
Environment
- Claude Code CLI, Opus-class model, paid subscription
- Long sessions (6-8h) reviewing pull requests on an open-source cloud-service emulator
- Custom instructions supplied in both a project instruction file and a persistent memory directory, loaded automatically at session start
- Incidents are taken from transcripts recorded as they happened across three consecutive sessions, within a 90-day pattern
---
Co-authored with Claude Code.