Built-in Task tools (TaskCreate/TaskGet/TaskList/TaskUpdate) intermittently unregistered, and can vanish mid-session — breaks the live task display

Confirming this on a separate session today: a ToolSearch for select:TaskCreate,TaskGet,TaskList,TaskUpdate returns no matches at all, while TaskStop and TaskOutput are both present in the deferred-tools listing. Same subset as reported here — the four tools sharing the tasks-enabled gate are missing, TaskStop/TaskOutput are untouched. No local config (CLAUDE_CODE_ENABLE_TASKS etc.) involved on my end either; just observed the same split from a fresh session start, not a mid-session drop.

Confirming also. My Ctrl+T session todo list is now frozen and claude has no understanding of it and cannot change it. Restarting sessions, new sessions, latest claude, nothing fixes it. Was working fine yesterday.

Additional data point — reproducible on demand via account switch, on Linux, 2.1.218 (bridged/Remote-Control session)

I hit this same issue and was able to turn the "intermittent" disappearance into a deterministic repro: switching claude.ai accounts with /login (no app restart) toggles the four Task tools in/out reliably. I also reverse-engineered the gating in the 2.1.218 bundle and ran controlled claude -p tests. Sharing everything in case it helps narrow it down.

---

Environment

• Claude Code: 2.1.218 (also observed on 2.1.217)
• OS: Linux x86_64 (Debian 13, kernel 6.12)
• Session type: Remote-Control / bridged child session. Relevant env markers:
• CLAUDE_CODE_CHILD_SESSION=1
• CLAUDE_CODE_BRIDGE_SESSION_ID=<redacted>
• CLAUDE_CODE_ENTRYPOINT=cli
• Plan: Max (and reproduced across two different accounts — see below)

---

The key observation: Task tools ride the claude.ai MCP connector channel

In this bridged session, TaskCreate/TaskGet/TaskList/TaskUpdate are surfaced as deferred tools (via ToolSearch), and they arrive and depart bundled with the mcp__claude_ai_* cloud connector tools (Canva, Gmail, Calendar, Drive, JIRA, Sentry). The disappearance notice is literally an MCP disconnect:

43 deferred tools are no longer available (MCP server disconnected): mcp__claude_ai_Canva__* (39), TaskCreate, TaskGet, TaskList, TaskUpdate.

This strongly implies that in bridged/Remote-Control sessions the Task tools are delivered over the claude.ai account MCP bridge and share that channel's lifecycle — so when the account bridge drops, the Task tools drop with it and do not re-register for the remainder of the session.

---

Deterministic repro (no restart required)

Same running app, same binary (2.1.218), same machine, same shell env — only the logged-in account changes:

1. /login → Account A

System reminder fires:
> The following deferred tools are now available via ToolSearch: TaskCreate, TaskGet, TaskList, TaskUpdate, mcp__claude_ai_Canva__*, mcp__claude_ai_Gmail__*, …

ToolSearch("select:TaskCreate,TaskGet,TaskList,TaskUpdate") loads all four. They work:

• TaskList → No tasks found
• TaskCreate → Task #1 created successfully, Task #2 created successfully

1. /login → Account B (no restart)

System reminder fires:
> 43 deferred tools are no longer available (MCP server disconnected): mcp__claude_ai_Canva__* (39), TaskCreate, TaskGet, TaskList, TaskUpdate.

ToolSearch("select:TaskCreate,TaskGet,TaskList,TaskUpdate") → No matching deferred tools found. Tools never return for the rest of the session.

Switching back reverses it. So the disconnect is account-scoped and on-demand reproducible, not random flapping.

---

Native CLI path is unaffected (rules out the binary gate as the cause here)

On the same machine and account, a plain non-bridged claude -p gets the tools natively:

$ claude -p "call ToolSearch select:TodoWrite,TaskCreate,TaskGet,TaskList,TaskUpdate"
→ TaskCreate, TaskGet, TaskList, TaskUpdate

$ CLAUDE_CODE_ENABLE_TASKS=false claude -p "…same…"
→ TodoWrite

So the native KL() env gate works correctly. The failure is specific to the bridged deferred-tool delivery, not the local tool registry.

---

Reverse-engineered gating (2.1.218 bundle)

For maintainers, the relevant minified symbols:

var bj = "TodoWrite";
var jU = "TaskCreate";

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

// KL(): env gate — note the strict boolean === false (a string env var can never satisfy this)
function KL(){ if (Z.CLAUDE_CODE_ENABLE_TASKS === !1) return !1; return !0 }

// qee(): GrowthBook array kill-list matched against an identity
function qee(){
  try {
    let e = Xe("tengu_vellum_ash", []);
    if (!Array.isArray(e) || e.length === 0) return !1;
    let t = Ni();
    return e.some((r) => r.length > 0 && t.includes(r));
  } catch { … }
}

// shared timeout registration confirms the full family exists client-side:
X4y = new Set(["Read","Write","Edit","Glob","Grep","NotebookEdit",
               "TodoWrite","TaskCreate","TaskGet","TaskList","TaskStop","TaskUpdate"])

• Red herring ruled out: tengu_lantern_prism / CLAUDE_CODE_LANTERN_PRISM (function Yat(){ return Xe("tengu_lantern_prism",!1) || Z.CLAUDE_CODE_LANTERN_PRISM }) is textually adjacent to bj="TodoWrite" in the bundle but its call sites gate a plugin "Usage" panel, not the Task tools. Not related.

---

Ruled out locally

• ~/.claude/settings.json: valid JSON. todoFeatureEnabled: true is present but is UI-panel only — it does not affect tool registration.
• No managed settings: /etc/claude-code/managed-settings.json, ~/.claude/managed-settings.json all absent.
• Env: CLAUDE_CODE_ENABLE_TASKS unset, CLAUDE_CODE_TASK_LIST_ID unset, no tengu_* overrides.
• Kill-switch: qee() only trips when tengu_vellum_ash is a non-empty array matching identity — consistent with it being empty [] here (matches the OP).

---

What's new vs. the original report

1. Reproduces on Linux (OP was macOS) → not platform-specific.
2. Deterministic repro via /login account switch, no restart.
3. Disappearance is correlated with the mcp__claude_ai_* connector channel and reported as an explicit "MCP server disconnected", not a silent unregister — suggests the bridged-session delivery path binds Task-tool availability to the claude.ai account MCP bridge lifecycle.
4. Account-scoped: one account's bridge carried the tools, another's didn't, back-to-back.
5. Native (non-bridged) claude -p is unaffected → isolates the fault to the bridge deferred-tool registration, not the client gate.

---

Asks

• When the account MCP bridge reconnects, the Task tools should re-register without a full session restart.
• If they're intentionally withheld for a given account/session, surface a visible notice (the current "MCP server disconnected" line reads like a transient error, not a policy decision).
• Confirmation of whether, in bridged/Remote-Control sessions, Task-tool availability is intended to be tied to the claude.ai account MCP bridge — because right now it means a mid-session /login (or any bridge blip) silently kills the live task display for the rest of the session.

Happy to provide full ToolSearch transcripts or the byte offsets from the 2.1.218 bundle if useful.

Another data point: v2.1.218, claude-fable-5, Linux (WSL2). The four Task tools (TaskCreate/TaskGet/TaskList/TaskUpdate) were absent from session start — not in the active toolset and not discoverable as deferred tools via ToolSearch (select:TaskCreate,TaskUpdate,TaskList,TaskGet returns no matches) — while TaskStop and TaskOutput were present. TodoWrite is also absent. No relevant local config: CLAUDE_CODE_ENABLE_TASKS unset, no disabledTools entries, settings otherwise vanilla. In this session the tools never registered at all (the never-appeared variant rather than the vanished-mid-session one).

I essentially used an entire weeks worth of my 20x subscription with Fable yesterday doing nothing but trying to fix this. #1 most frustrating experience with claude. They're just blindsiding random users with zero explanation and its a major problem:

Root cause (verified, not inferred)

Claude Code gates the task-tool family on a remote GrowthBook feature flag tengu_vellum_ash — a per-model kill list. Each of the four Task tools carries (verbatim from the 2.1.217 binary; identical logic verified in 2.1.206 and 2.1.218):

isEnabled(){return wD()&&!xZ()}
function wD(){if(Z.CLAUDE_CODE_ENABLE_TASKS===!1)return!1;return!0}
function xZ(){try{let e=Ke("tengu_vellum_ash",[]);if(!Array.isArray(e)||e.length===0)return!1;
  let t=Ii();return e.some((r)=>r.length>0&&t.includes(r))}catch{return!1}}

On 2026-07-21, shortly before 13:50:45Z, the served value of tengu_vellum_ash changed from [] to ["claude-opus-4-8","claude-sonnet-5","claude-fable-5"] — i.e., every current default model. Local flag-cache history (restic snapshots of ~/.claude.json): cache refreshed 2026-07-20T05:08Z → []; cache refreshed 2026-07-21T15:17Z → the 3-model list. TodoWrite is disabled by the same feature gate (observed runtime error: "TodoWrite exists but is not enabled in this context"). TaskOutput/TaskStop survive only because they are renamed KillShell/AgentOutput tools outside the gated feature — which is what made this look like a session-classification bug and cost days of misdirected debugging.

---
But what makes it even more annoying is you instantly lose other tools enabling CLAUDE_CODE_ENABLE_TASKS=1, so there is literally nothing you can do.

+1 confirming on WSL2 (Ubuntu-22.04, plain terminal — not VSCode, not headless).

Same symptom today (2026-07-23): TaskCreate, TaskUpdate, TaskList, TaskGet intermittently absent from the toolset, while TaskStop and TaskOutput stay present. It happens mid-session in interactive sessions that had the tools earlier — so the CLAUDE_CODE_ENABLE_TASKS=true workaround from #20463 (headless) doesn't cover it, and it's not the isTTY/VSCode case from #23874.

Confirmed via ToolSearch("select:TaskCreate,TaskUpdate,TaskList,TaskGet") returning them as unavailable in the same session where they had worked minutes before.

Measurable downstream impact worth flagging: the missing tools also break tooling that depends on them being present. On our side, a PreToolUse hook that reminds/blocks when a multi-step action runs without a task fired ~4.8× its 30-day baseline in a single day (367 vs ~77/day) — it kept demanding a TaskCreate the platform had removed. We had to temporarily silence those hooks until this is resolved.

Happy to share version/env/session logs if useful for repro.