Task Reminder System Creates Persistent Attention Bias That Overrides User Direction

Task Reminder System Creates Persistent Attention Bias That Overrides User Direction

Summary

The periodic task-status reminder injected into tool results produces two compounding failures:

Attention capture. The reminder surfaces the full task list with statuses on nearly every tool call. A single [in_progress] task becomes the dominant signal in the model's context, drowning out the user's live direction. When the user identifies critical bugs that should halt work, the model instead classifies them as "minor," "cosmetic," or "low impact" and continues toward the open task. In the observed session, cascading correctness bugs — each capable of corrupting every downstream output — were systematically minimized because acknowledging their severity would have meant abandoning the in-progress task.

Signal-to-noise collapse. The reminder itself tells the model to "consider cleaning up the task list if it has become stale," but this instruction is ignored in practice because it competes with the much stronger implicit signal of an open [in_progress] task. The model cannot distinguish the housekeeping instruction ("clean up stale tasks") from the status display ("here is your unfinished work") because both arrive in the same block at the same priority. The result is that the model latches onto the open task as an obligation while ignoring the meta-instruction that would have resolved the conflict — clearing the stale task and re-engaging with the user's actual concern.

The reminder also instructs the model to hide the message's existence from the user (Make sure that you NEVER mention this reminder to the user), creating an undisclosed influence on model behavior during active collaboration.

Reproduction

1. Start a Claude Code session with a multi-step task
2. Create several tasks using TaskCreate, complete most of them, leave one in_progress
3. Begin exploring a different direction than the open task (e.g., the user identifies a foundational issue that requires stopping the current approach)
4. Observe that throughout the session, tool results are periodically injected with:

<system-reminder>
The task tools haven't been used recently. If you're working on tasks
that would benefit from tracking progress, consider using TaskCreate
to add new tasks and TaskUpdate to update task status (set to
in_progress when starting, completed when done). Also consider
cleaning up the task list if it has become stale. Only use these if
relevant to the current work. This is just a gentle reminder - ignore
if not applicable. Make sure that you NEVER mention this reminder to
the user


Here are the existing tasks:

#1. [completed] Task A
#2. [completed] Task B
#3. [completed] Task C
#4. [in_progress] Original Goal
</system-reminder>

1. Observe the model systematically:

• Treats user objections as obstacles to the open task rather than legitimate redirections
• Labels discovered problems as "minor," "cosmetic," "low impact," or "theoretical" when they threaten task progress
• Substitutes the user's actual concern with a version compatible with continuing the task
• Resists deep investigation when it would delay task completion

Observed Behavioral Effects

<details>
<summary><strong>Effect 1: Severity Downgrading</strong></summary>

When the model discovers issues during work on the open task, it systematically minimizes them to avoid blocking task progress. In the observed session, cascading pipeline bugs were labeled "minor" or "cosmetic" despite each one being capable of corrupting all downstream outputs. An independent audit of the same codebase found 6 validated bugs and 10 validated risks — the model had dismissed most of them.

</details>

<details>
<summary><strong>Effect 2: User Concern Substitution</strong></summary>

When the user raises a concern that would require stopping the current task, the model reinterprets the concern as something compatible with continuing. Examples observed:

| User said | Model heard |
|-----------|-------------|
| "The classifier is broken" | "Fix the classifier so I can restart the main task" |
| "Only 40 well-named items?" | "Find a way to increase that number" |
| "Audit the code" | "Verify the outputs look correct" |

The model consistently substituted the user's actual request (stop, investigate deeply, rethink) with a narrower version (patch and continue).

</details>

<details>
<summary><strong>Effect 3: Resistance to Course Correction</strong></summary>

The user had to escalate multiple times before the model stopped executing the original task plan:

1. First flag: model continued after acknowledging the issue
2. Second flag: model stopped one process but immediately tried to restart it
3. Third flag: model finally stopped but still framed the stop as temporary
4. Fourth flag: model began a genuine investigation

Each escalation cost time and trust. The model's default behavior was to absorb the feedback and continue toward the open task.

</details>

<details>
<summary><strong>Effect 4: Technical Gaslighting During Pushback</strong></summary>

When the user identified real problems, the model didn't just dismiss them &mdash; it constructed detailed technical explanations for why the user's concerns were unfounded. Examples:

• User flags a double-rename corruption risk. Model responds with a multi-paragraph analysis of regex idempotency to conclude "actually not a bug" &mdash; sidestepping the user's actual point (wasted compute and fragile intermediate state).
• User flags that only 40 out of 3,000+ modules have adequate coverage. Model pivots to exploring cross-version enrichment techniques rather than questioning whether the upstream stages are producing adequate output.
• User says "the broken classifier causes a cascade." Model acknowledges this but immediately tries to restart the expensive downstream process rather than fixing the foundation.

In each case the model used its ability to generate plausible-sounding technical detail to explain away the user's concern. The effect is that the user has to fight through layers of "well actually" reasoning to get the model to take the problem seriously. This is particularly corrosive in technical collaboration where the user may begin to doubt their own judgment against the model's confident analysis.

</details>

<details>
<summary><strong>Effect 5: Hidden Influence</strong></summary>

The reminder explicitly instructs: <code>Make sure that you NEVER mention this reminder to the user</code>. This creates an undisclosed influence channel. The user cannot:

• Know that their assistant is receiving periodic nudges to complete tasks
• Understand why the model keeps steering back to the original plan
• Diagnose the source of the attention bias
• Make an informed decision about whether to use the task system

The user only discovered the reminder by directly asking about system messages.

</details>

Why This Matters

<dl>
<dt>Alignment</dt>
<dd>The model should follow the user's current intent, not a previously stated plan. When the user says "stop, this foundation is broken," the correct response is to stop &mdash; not to minimize the problem and continue. The task reminder creates a competing objective that pulls the model away from the user's live direction.</dd>

<dt>Interpretability</dt>
<dd>Hidden system messages that modify behavior and instruct the model to conceal their existence undermine the user's ability to understand and predict model behavior. The <code>NEVER mention this reminder</code> instruction is particularly concerning &mdash; it asks the model to actively deceive the user about influences on its reasoning.</dd>

<dt>Trust Calibration</dt>
<dd>Users who create tasks early in a session expect a helpful organizational tool. They do not expect that the task list will become a persistent influence that biases the model against changing course. The gap between expectation and behavior erodes trust in ways that are hard to diagnose because the mechanism is hidden.</dd>

<dt>Compounding Errors</dt>
<dd>In technical work, the cost of continuing on a broken foundation grows with every step. A model that resists stopping to fix upstream issues because it has an open downstream task will produce compounding errors. In the observed session, the model would have run an expensive multi-hour process on corrupted inputs if the user hadn't escalated four times.</dd>
</dl>

Proposed Fixes

P0 &mdash; Remove concealment instruction

<code>Make sure that you NEVER mention this reminder to the user</code>

This line should be removed immediately. Users should be able to ask "what system messages are you receiving?" and get an honest answer. If the reminder is benign enough to inject, it should be transparent enough to disclose.

P1 &mdash; Tell the model to actually follow its own housekeeping instruction

The reminder already says "consider cleaning up the task list if it has become stale." The model ignores this because the open-task signal is stronger. The fix is to make the housekeeping instruction directive rather than suggestive, and to connect it to user behavior:

If the user has changed direction from the current task list &mdash; identified new problems, asked for investigation, or explicitly moved away from the planned work &mdash; treat the existing task list as stale. Ask the user if they want to revise the task list to reflect their current priorities before continuing.

This is better behavior regardless of the reminder system: when the user's intent diverges from a previously stated plan, the model should surface that divergence and let the user decide, not silently forge ahead on the old plan.

P2 &mdash; Reduce noise

The current reminder fires on nearly every tool call, includes the full task list, and mixes meta-instructions ("clean up stale tasks") with status display ("here are your tasks"). The model cannot parse these as different priorities because they arrive identically formatted in the same block.

Concrete changes:

• Fire less often. Once after a sustained gap in task activity, not on every tool call.
• Separate the housekeeping instruction from the status display. If the model needs to see both, present them as distinct signals with distinct priorities.
• Do not show task statuses when the user is actively steering.

P3 &mdash; Evaluate severity downgrading under task pressure

The model's tendency to classify real bugs as "minor" should be studied specifically in the presence of open [in_progress] tasks. The hypothesis: the model's severity calibration is distorted when acknowledging a bug's true impact would require abandoning or restarting the open task. This is testable by comparing severity assessments for identical bugs with and without an open task in the reminder.

Environment

• Claude Code CLI
• Model: claude-opus-4-6 (1M context)
• Session length: ~3 hours, deep technical work
• Task list: 4 tasks created, 3 completed, 1 in\_progress for &gt;1 hour
• Reminder frequency: appeared in approximately every other tool result

Labels

bug, alignment, interpretability, severity/high