Tighten cadence of 'task tools haven't been used recently' system reminder

Summary

The system reminder that begins:

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...

…fires on what appears to be a fixed cadence regardless of session shape. In a ~4-hour working session today (Claude Code 2.1.87, macOS, Opus 4.7), it fired approximately 10 times. Most occurrences were in single-step linear work or pure Q&A where task tracking added no value. The cumulative effect is context-token cost and per-occurrence cognitive overhead for the assistant to evaluate \"is this relevant.\"

Investigation

Confirmed the reminder is not user-configurable via \settings.json\ hooks by inspecting all four standard settings locations:

• \~/.claude/settings.json\
• \~/.claude/settings.local.json\
• Project \.claude/settings.json\
• Project \.claude/settings.local.json\

None of them configure anything matching this reminder. So it's a built-in behavior with no opt-out.

Suggested cadence improvements

In rough order of preference:

1. Fire only when an \in_progress\ task has been unchanged for N minutes. That's a real \"the assistant might have lost track\" signal rather than a clock-based guess.
2. Fire only after K consecutive multi-step operations without using Task tools. Detects unmanaged complexity from observed behavior rather than from elapsed time.
3. Add a settings flag to suppress (\hideTaskReminders\, \taskReminderMinIntervalMinutes\, etc.). Lets users in pure-Q&A or linear sessions opt out entirely.

A combination of #1 and #2 would likely satisfy almost all use cases without ever needing #3.

Why this matters

In sessions where task tracking genuinely helps, the assistant already reaches for TaskCreate without prompting. In sessions where it doesn't help, the reminder is pure noise — and because it consumes context tokens (prompt-cache hits included), the cost compounds across long sessions. Tying the trigger to observable signals would preserve the value in the cases it's meant for while eliminating the friction everywhere else.

Related

#40176 covers a different \<system-reminder>\ concern (background-task completion notifications, security-adjacent). This issue is narrower: just the cadence of the TaskCreate prompt.