Context poisoning
Learn what context poisoning is, how to recognize it in a Bob Shell session, and how to recover by starting a fresh session or improving context hygiene.
About context poisoning
Context poisoning is when wrong or irrelevant information gets into the context window and stays in the transcript. Bob treats the information as fact on follow-up prompts. Replies drift. Tool calls become inaccurate. The work goal gets lost.
This is different from a single bad answer. The bad data sits in Messages (or came in through a file read, command output paste, or outdated comment). Bob re-sends it on every prompt until you reset or start a new session.
For how the window fills and when to start fresh, see Context window management.
Symptoms
You are likely dealing with context poisoning when you notice any of the following:
- Worse output: Suggestions repeat, wander, or stop matching the repo.
- Wrong tool use: Tool steps in the transcript no longer match what you asked for.
- Stuck multi-step work: Long multi-prompt flows loop or stall.
- Short-lived fixes: A corrective prompt helps once, but then the problem returns.
- Tool confusion: Bob misuses tools even though Tool definitions did not change.
If Messages is already large, check your token usage first. Poisoning and an overfull window often occur together.
Common causes
| Cause | What happens |
|---|---|
| Bad facts in the session | Bob states something incorrect. Later exchanges treat it as ground truth in Messages. |
| Stale or wrong repo text | Outdated comments, README fragments, or generated docs mislead file reads. |
| Oversized pastes | Logs or snippets with noise, truncation, or hidden characters land in Messages. |
| Condensation | Bob summarizes older Messages. Useful detail disappears. What remains can dominate the session. |
| Irrelevant context | Unrelated files, old plans, or a prior work goal still exist in the transcript. |
Once bad context is in Messages, it persists across every subsequent prompt. Bob does not reliably ignore plausible text just because it is wrong.
Limitations of corrective prompts
Pasting Tool definitions, rules, or a strict corrective prompt into the conversation might mask the problem for one or two exchanges. The poisoned Messages history is still there. The next off-topic question can bring the same failure back.
The reliable fix is a new session: exit and run bob again to start fresh. This clears poisoned Messages while keeping Rules and project files on disk.
Recovery
- Start a new session by exiting and running
bobagain. This clears poisoned Messages while keeping Rules and project files on disk. - Paste less. Send only the log lines or errors Bob needs. Large dumps increase Messages and introduce more risk.
- Split the work goal. Use separate sessions for unrelated steps so that a stale transcript does not carry over.
- Check tool output. If a tool returns garbage, stop and start a new session rather than letting Bob build on it in Messages.
- Trust tests over text. When comments and code disagree, point Bob at runnable checks. This is the same guidance as context window best practices.
Prevention
Most prevention is a result of good context hygiene:
- Scope the work goal before repo exploration (context window management).
- Keep
AGENTS.mdand Rules short and operational. - Add files and logs when needed, not up front.
- Reset when Messages grows without progress.
For repo-wide reads, use subagents so that the session sees subagent results, not every tool step in Messages.
Learn more
Context window management
Learn how Bob's 270,000-token context window works, how each category contributes to token usage, and best practices for keeping sessions focused and cost-efficient.
Working with large projects
Manage large codebases in Bob Shell. Understand context window optimization, file handling, and best practices for enterprise-scale projects.