Native TaskCreate/TaskUpdate/TaskList/TaskGet become permanently unavailable mid-session, survives /clear and a full process restart

This is a useful capability-continuity failure to pin down. The sharp edge is not just that a tool disappeared; it is that the session still has enough identity to keep operating while one documented capability class silently changes underneath it.

For workflows that recreate or audit state after restart, I would want two explicit signals:

• a capability manifest/version attached to the session, including deferred native tools, so the agent can tell whether TaskCreate/TaskUpdate/TaskList/TaskGet were ever in its contract for this run;
• a negative capability event when a native tool family becomes unavailable, with a reason class such as policy_changed, lazy_loader_failed, server_side_withdrawn, or unknown.

Without that, downstream skills cannot distinguish "I am misconfigured" from "the runtime contract changed after I started." That is the same boundary AgentFolio/SATP keeps running into for agent trust: authorization says what the agent may do at a point in time, but identity/reputation systems also need a stable record of what capabilities the agent claimed and when that claim stopped being true.

No claim of integration or endorsement here, just the architectural implication: a silent capability withdrawal should probably be observable as a first-class runtime event, not only discovered by failed ToolSearch calls.

Further diagnostics — still unresolved.

Continued investigating with the CLI binary itself rather than just the running session:

• Ran strings against the installed CLI binary (2.1.207, /Users/fishliver/.local/share/claude/versions/2.1.207) and confirmed TaskCreate, TaskUpdate, TaskList, TaskGet are all present as literal strings, including their full tool descriptions/help text. They are not stripped, removed, or renamed in this build.
• Broader ToolSearch keyword queries ("task list create update tracker", "todo write read tracker") surface no alternate/renamed tool either.
• claude mcp list shows no server that could plausibly back these tools — consistent with the docs describing them as native (not MCP-backed), which rules out an MCP disconnect as the cause.
• Checked both ~/.claude/settings.json and the current project's .claude/settings.local.json — no permission allow/deny rule references these tools or anything that would explain a deny.
• claude update confirms the CLI is already on the latest available version (2.1.207) — rules out "a pending update was needed."
• Still unavailable after both a /clear and a full claude process quit + relaunch (confirmed via distinct PIDs before/after the relaunch).

At this point the tools are confirmed present in the binary but not registering as callable in this session, through several restart/update paths that would normally clear a stale-state issue. Continuing to investigate; will follow up if we isolate the actual trigger.

Further diagnostics — three candidate activation paths tested, all negative.

Traced the tool-registry gating logic directly in the CLI binary (2.1.207) and found the literal array-inclusion check for these four tools:

function iH(){if(ou(process.env.CLAUDE_CODE_ENABLE_TASKS))return!1;return!0}
// ...
...iH()?[Exd,Axd,Ixd,Lxd]:[]  // Exd=TaskCreate, Axd=TaskGet, Ixd=TaskUpdate, Lxd=TaskList

(ou() only returns true for an explicit "0"/"false"/"no"/"off" value; unset defaults to enabled.)

Tested three candidate env vars/keybindings, each launched correctly before the claude process starts (not set mid-session — env vars set via a Bash tool call inside an already-running session only reach that subprocess's children, not the parent Node process's own fixed process.env, which makes mid-session testing of any process.env-gated behavior a false negative):

1. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 — no effect on ToolSearch results for these 4 tools.
2. The ctrl+t "toggle tasks" keybinding shown in /help — no effect.
3. CLAUDE_CODE_ENABLE_TASKS=1 — the literal gate shown above — confirmed reaching the process (echo $CLAUDE_CODE_ENABLE_TASKS → 1 inside that session), and ToolSearch still returned "No matching deferred tools found" for all four.

So the one condition the binary's own code shows as sufficient (iH() returning true) was satisfied and the tools still didn't register. That's consistent with an additional gate not visible in static analysis of the binary — most plausibly a server-side/account-level flag (this account's cached GrowthBook feature-flag snapshot separately shows an unrelated killswitch-style flag, tengu_vellum_ash, though I can't confirm whether that specific one is in the actual resolution path for these tools) rather than anything fixable from the client.

Submitted a private /feedback report (session-scoped) referencing this issue in case the attached session detail is useful. Otherwise this is likely at the limit of what's diagnosable from the client side — happy to run further tests if anyone from the team has a specific one in mind.

This looks like the same root cause as #77577 — a cached experiment flag (tengu_vellum_ash)
that gates the four entity-tracker tools by model ID, rather than anything session-scoped.

That would explain the two things you found most puzzling: /clear and a full process restart
don't help because the flag is cached in ~/.claude.json and re-read on startup, so there is no
session state to reset. Your observation that TaskOutput and TaskStop survive also fits —
those are background-task tools and aren't covered by the gate.

Confirmed the same payload on 2.1.216 here: ["claude-opus-4-8", "claude-sonnet-5", "claude-fable-5"].
If the model you were on when they vanished is one of those three, that's almost certainly it.

One workaround while it's open: headless (-p) sessions still get all four tools on gated models,
so scripted paths keep working even though interactive ones don't. Downgrading the CLI does not
help — 2.1.214/215/216 all behave identically, since the flag is shared across installed versions.