TaskCreate reminder fires despite explicit "Do NOT use TaskCreate" directive in CLAUDE.md

Summary

The harness periodically injects a <system-reminder> suggesting TaskCreate/TaskUpdate usage even when the user's CLAUDE.md contains an explicit instruction not to use those tools. The reminder is not context-aware of user-scope rules, so it fires on every session. The agent then has to either comply (violating the user rule) or acknowledge the conflict in output — neither outcome should be necessary.

Reproduction

The same agent turn that includes my CLAUDE.md (which says "Do NOT use TaskCreate") also includes the reminder telling me to use it. Specifically:

1. The harness's own system-prompt segment introduces user CLAUDE.md with:

> # claudeMd
> Codebase and user instructions are shown below. Be sure to adhere to these instructions.
> IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written.

1. That segment then includes my ~/.claude/CLAUDE.md, which contains a ## Task System Isolation (MANDATORY) block with Do NOT use TaskCreate for session-local work.

1. Later in the same turn, the harness injects:

``
<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.
</system-reminder>
``

So the reminder is injected into a turn where the model has already been told CLAUDE.md is authoritative and CLAUDE.md explicitly prohibits the tool being recommended.

The opt-out the harness ignores

My user-scope ~/.claude/CLAUDE.md contains:

## Task System Isolation (MANDATORY)

`TaskCreate`/`TaskList` stores tasks globally — every session sees every task, causing cross-talk.

- Do NOT use `TaskCreate` for session-local work. Track progress via `## Progress` blocks in responses.
- `TaskCreate` only for intentionally shared cross-session coordination items with metadata: `{ "scope": "shared", "sessionId": "<id>", "purpose": "coordination" }`
- If `TaskList` shows tasks you didn't create, ignore them.

This is a deliberate, considered policy. I moved cross-session coordination to a different system (a self-hosted MCP daemon) precisely because the global task store leaked between unrelated work.

The friction

Every time the reminder fires, the agent faces two suboptimal paths:

1. Comply with the reminder → violates the explicit user rule, creates the cross-session leak the user opted out to avoid.
2. Ignore the reminder and acknowledge in text → spends output tokens on something like "ignoring task reminder per CLAUDE.md." Breaks response flow. Re-litigates a decision the user made permanent.

The third option — silently ignore the reminder, never mention it — is the right behavior, but in practice the agent takes several sessions to settle into it, and occasionally slips back. The reminder is invisible to the user (it lives inside a <system-reminder> tag the UI doesn't render), so the user never sees what the agent is reacting to, only the reaction.

Suggested fix

Any of these would resolve the friction. Listed in order of implementation simplicity:

1. User-settings flag. Add a disableTaskCreateReminder: true option (or a more general disabledReminders: [] array) to ~/.claude/settings.json. Simplest, deterministic, follows existing config patterns.

1. Structured opt-out directive in CLAUDE.md. Define a recognized directive — e.g., a YAML frontmatter key like taskCreateReminder: false, or a documented marker the harness scans for — so suppression is policy-level rather than ad-hoc prose pattern matching. The system prompt already promises CLAUDE.md "OVERRIDE[s] any default behavior"; surfacing an explicit, structured way to opt out of this nudge makes that promise actionable.

1. Coordination-aware suppression. When the session has registered an alternative task-coordination MCP server, suppress the reminder by default. Implementation detail (capability flag in the MCP manifest, etc.) is the harness team's call.

Option 1 is the cleanest single ask.

Why this matters beyond my one account

Anyone who has migrated to an alternative task system — a project-local issue tracker, a coordination daemon, a personal Linear/Notion/etc. workflow — runs into the same problem. The reminder assumes the only reason TaskCreate is unused is forgetfulness, when in many cases it is a considered choice.

Environment

• Claude Code CLI (current as of 2026-05-18)
• Platform: Windows 11
• Model: Opus 4.7 (1M context); observed under Sonnet 4.6 as well
• Reminder fires reliably within the first 5–10 turns of any taskful session