[BUG] TaskCreate and TodoWrite both disabled on Opus 4.8 / Sonnet 5 / Fable 5 by a server-side model gate — no fallback, no local override

Summary

On Claude Code v2.1.218 in the terminal CLI, TaskCreate / TaskGet / TaskList / TaskUpdate and TodoWrite are all unavailable — not in the main session, not to spawned agents, and not discoverable via ToolSearch.

The cause is a server-side remote-config gate keyed on the model id. tengu_vellum_ash currently holds ["claude-opus-4-8", "claude-sonnet-5", "claude-fable-5"], and the match is a substring test, so every session on the three newest models loses task tracking entirely.

This is distinct from #23816 and #23874 (both closed, v2.1.34, VSCode, isTTY). The isTTY branch those reported is gone from the current gate; this is a different and additional mechanism, and unlike the old one it disables the TodoWrite fallback too.

Reproduction

1. Run the terminal CLI (a real TTY — this is not the VSCode/pipe case) on v2.1.218.
2. Select any of claude-opus-4-8, claude-sonnet-5, claude-fable-5.
3. Ask the model to create a task list, or have it call ToolSearch with select:TaskCreate,TaskUpdate.

Observed:

ToolSearch("select:TaskCreate,TaskUpdate") -> No matching deferred tools found
ToolSearch("select:TodoWrite")             -> No matching deferred tools found

Expected: the task tools are registered with shouldDefer: true, so ToolSearch should resolve them.

Root cause

Both tools are registered with an isEnabled predicate sharing one clause:

// TaskCreate
isEnabled(){ return  KL() && !qee() }
// TodoWrite
isEnabled(){ return !KL() && !qee() }

KL() selects which subsystem is active (Task tools vs legacy TodoWrite):

function KL(){ if (env.CLAUDE_CODE_ENABLE_TASKS === false) return false; return true }

qee() disables both:

function qee(){
  try {
    let e = Xe("tengu_vellum_ash", []);   // server-side remote config
    if (!Array.isArray(e) || e.length === 0) return false;
    let t = Ni();                          // current model id
    return e.some(r => r.length > 0 && t.includes(r));   // substring match
  } catch { return false }
}

Observed live value (from the local config cache, 2026-07-23):

"tengu_vellum_ash": ["claude-opus-4-8", "claude-sonnet-5", "claude-fable-5"]

Because the test is t.includes(r), context variants match too — claude-opus-4-8[1m] matches claude-opus-4-8.

Why this is worth reporting

1. No fallback. KL() only chooses between two subsystems; qee() takes out both. Progress-list tracking is not degraded to the legacy path — it is absent. That is a capability regression, not a migration.
2. No local override. CLAUDE_CODE_ENABLE_TASKS is one-way: it can only force KL() false. Nothing can override qee(). Users cannot restore the feature except by moving to an older model.
3. Silent and undocumented. No changelog entry through v2.1.218 mentions it — the changelog still lists improvements to TaskCreate. The Todo Lists docs present the Task tools as the default since v2.1.142 with no model-availability caveat.
4. It breaks published guidance. The TeamCreate/agent-teams workflow and the SDK migration guide both instruct callers to use TaskCreate/TaskUpdate. Any prompt, skill, or SDK integration that mandates a task list now fails on the default models, with no diagnostic — the tool is simply not in the list.
5. Remote config means it can change with no release. The tengu_vellum_ash gate is present in every build I have back to v2.1.207, so a version diff does not explain when or why the behavior changed. That makes it very hard to self-diagnose — the tools worked recently on this same machine.

Environment

• Claude Code 2.1.218 (native install, ~/.local/share/claude/versions/2.1.218)
• Terminal CLI, real TTY — not the VSCode extension
• Linux 6.17.0-35-generic
• Model: claude-opus-4-8[1m]
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• CLAUDE_CODE_ENABLE_TASKS unset
• No disabledTools/deny rules for these tools in user, project, or local settings

Verified the names are unchanged and present in every installed build (2.1.207 → 2.1.218), so this is not a rename or removal:

| Version | TaskCreate | TaskUpdate | TodoWrite |
|---|---|---|---|
| 2.1.207 | 33 | 24 | 13 |
| 2.1.211 | 34 | 24 | 13 |
| 2.1.215 | 31 | 24 | 13 |
| 2.1.216 | 30 | 24 | 13 |
| 2.1.217 | 30 | 24 | 13 |
| 2.1.218 | 30 | 24 | 13 |

(occurrence counts of each literal in the bundle)

Questions

1. Is the model gate intentional, and if so what is the criterion for a model landing on tengu_vellum_ash?
2. If it is a mitigation for malformed TaskCreate calls on newer models, could it fall through to TodoWrite rather than disabling tracking outright? The !qee() clause on TodoWrite looks like it may be unintended — dropping it would preserve a working fallback.
3. Could this surface to the user? A one-line notice, a /status entry, or a /doctor warning would turn a silent capability loss into a diagnosable one.
4. Could the documentation note that task tooling is model-dependent, so SDK integrations know to handle its absence?