[BUG] TaskCreate/TaskList/TaskUpdate/TaskGet tools missing from session tool roster on Windows (v2.1.216/v2.1.217)

Status Closed — duplicate

Reported on v2.1.217

Maintainer reply None cached

Activity 5 comments · opened Jul 22, 2026 · closed Aug 15, 2026

Summary

The built-in task-tracking tools (TaskCreate, TaskList, TaskUpdate, TaskGet, and the legacy TodoWrite) are entirely absent from the session tool roster on Windows since approximately 2026-07-20/21. They are not available as direct tools, and they are not discoverable as deferred tools: ToolSearch with query select:TaskCreate,TaskList,TaskUpdate,TaskGet,TodoWrite returns No matching deferred tools found. A keyword sweep only surfaces unrelated tools (TaskOutput, TaskStop, Cron tools).

Observed consistently across 5+ consecutive sessions and multiple fresh restarts. The timeline correlates exactly with the v2.1.216 (Jul 20) / v2.1.217 (Jul 21) auto-updates on the latest channel. Neither changelog mentions any change to the task tools.

Environment

Running: native (2.1.217)
Commit: 9963b018d22c
Platform: win32-x64 (Windows 11 Home 10.0.26200)
Path: C:\Users\kadmo\.local\bin\claude.exe
Config install method: native
Auto-update channel: latest
Last update attempt: success -> 2.1.217 (2026-07-22)
No installation issues found.

Interactive terminal sessions (Git Bash / Windows Terminal), not headless, not the VSCode extension.

Steps to reproduce

Windows 11, Claude Code 2.1.217, latest channel, interactive CLI session in any repo.
Ask Claude to create a task list, or to run ToolSearch with select:TaskCreate,TaskList,TaskUpdate,TaskGet,TodoWrite.
Result: No matching deferred tools found. No task tools anywhere in the roster.

Expected

Task tools present by default. Per the Agent SDK docs (agent-sdk/todo-tracking.md), Task tools are the default since v2.1.142, with CLAUDE_CODE_ENABLE_TASKS=0 opting back into TodoWrite.

User configuration ruled out

CLAUDE_CODE_ENABLE_TASKS verified UNSET at every scope (docs default = enabled), and the tools were present with it unset before ~2026-07-20.
Full audit of user/project/local settings performed (a /doctor-assisted cleanup); the absence persists in fresh sessions with clean, schema-valid settings.
Explicitly setting "todoFeatureEnabled": true and "env": {"CLAUDE_CODE_ENABLE_TASKS": "1"} in ~/.claude/settings.json has been applied as a test; result pending a session restart. I will update this issue if it resolves the absence.

Possibly related

#23874 (task tools disabled in the VSCode extension due to the isTTY check when communicating over pipes) — different surface, but the same class of mechanism could explain this if a recent change altered TTY detection on win32. These sessions run in a regular interactive terminal, where isTTY should be true.

Impact

Task list tracking is a core part of my workflow (session-to-session task handoff). Currently working around it with an on-disk handoff note, but the native task panel has been unavailable for 3+ days.

Request

Investigate as a regression in v2.1.216/v2.1.217 on win32. Happy to provide --debug logs or run diagnostics if useful.

View original on GitHub ↗

4 Comments

Kadmon7 · 1 month ago

Update — negative result on the config-side fix attempt.

After filing this issue we found that the settings schema does define todoFeatureEnabled ("Enable the todo / task tracking panel"). We set todoFeatureEnabled: true in global ~/.claude/settings.json AND env.CLAUDE_CODE_ENABLE_TASKS="1", then fully restarted Claude Code.

Result: a fresh session on v2.1.217 (win32-x64, native) still has NO TaskCreate/TaskList/TaskUpdate/TaskGet in the tool roster — verified via ToolSearch direct select: lookup ("No matching deferred tools found") plus a keyword sweep. This is the 6th consecutive session since ~2026-07-20/21 without the tools.

So both config channels (settings key + env var) are ruled out as the cause or the fix. Next step on our side: pinning back to v2.1.215 to bisect whether 2.1.216 introduced it.

ArmoredArtist · 1 month ago

I can confirm this regression with additional version and headless-vs-interactive evidence.

My local interactive-session transcripts show:

2.1.214: TaskCreate calls present
2.1.215: TaskCreate calls present; last observed working version
2.1.216: zero TaskCreate calls across three interactive sessions
2.1.217: zero TaskCreate calls across nine interactive sessions

In 2.1.217 interactive sessions, ToolSearch reports no matching deferred tools for TaskCreate, TaskUpdate, TaskGet, or TaskList, and no ~/.claude/tasks/<session-id>/ task-store directory is created.

Headless mode is unaffected on the same installation. claude --model <model> -p "..." successfully creates and lists tasks and writes the task-store file. This worked with Haiku, Fable, Sonnet, and Opus, both inside and outside the project directory.

My environment is Windows using standalone PowerShell/Windows Terminal with an npm-global Claude Code installation. CLAUDE_CODE_ENABLE_TASKS is unset, and no local tool denial, restrictive allowlist, custom agent, or managed settings were found.

This strongly supports an interactive-session regression beginning in 2.1.216, although I have not yet performed a controlled reinstall of 2.1.215.

Kadmon7 · 1 month ago

Corroborating @ArmoredArtist's bisection from a different install type — with one divergence worth checking.

Same break, different environment. Native installer (not npm-global), Git Bash on Windows 11, v2.1.217. Their report is npm-global + PowerShell/Windows Terminal, so install method and shell are both ruled out.

Config is conclusively ruled out on our side. We tried the settings knobs explicitly, not just defaults: todoFeatureEnabled: true plus env.CLAUDE_CODE_ENABLE_TASKS="1", restart — still absent. Then "0" (legacy TodoWrite path), restart — TodoWrite absent too. Then the var removed entirely and a headless run with --settings pointed at an empty {} file — still absent. @ArmoredArtist has the var unset by default and sees the same thing, so the setting is inert in both directions.

Divergence: headless is NOT unaffected here. claude --model haiku -p "..." reports NO_TASK_TOOLS on this machine, under all three config states above, including the isolated empty-settings run. That contradicts their headless result on the same version, which suggests the trigger is narrower than "interactive vs headless" — possibly install-method- or platform-dependent. Worth pinning down, since it is currently the only reported workaround.

Task-store timeline supports the 2.1.216 bisection. ~/.claude/tasks/ here holds 29 session directories; the newest is dated 2026-07-20 22:50. Nothing has been written since, which lines up with 2.1.216/217 landing and matches their "2.1.215 last observed working".

jvitorcalmon · 1 month ago

Same regression here on Windows 11 (win32-x64), Git Bash. Can confirm and add a couple of data points that may help narrow it down.

Repro / confirmation

TaskCreate, TaskList, TaskUpdate, TaskGet and legacy TodoWrite are all absent from the tool roster — not as direct tools, not as deferred tools.
ToolSearch select:TaskCreate,TaskList,TaskUpdate,TaskGet,TodoWrite → No matching deferred tools found.
CLAUDE_CODE_ENABLE_TASKS unset; setting it made no difference, matching the report.
In my case the tools were present and working earlier in the same session, then disappeared after an auto-compaction and did not come back on --resume/--continue. So it's not only cold-start: an in-session event (compaction) can also drop them.

Data point that isolates it to the tool roster, not the task subsystem
The underlying task store keeps working even while the tools are gone:

~/.claude/tasks/<session-id>/*.json continue to exist, and the Ctrl+T panel still renders titles + status from them.
Editing those JSON files directly (status field) is reflected by the Ctrl+T panel — the persistence/render path is intact.
Only the model-facing tool roster is missing the Task*/TodoWrite entries.

That lines up with the TTY-detection suspicion (#23874): the gate that hides the task tools seems to be flipping based on TTY/terminal state, independent of the task store itself. The fact that it can flip mid-session (post-compaction) rather than only at startup might be a useful clue about where the isTTY check is being re-evaluated.

Environment:

OS: Windows 11 (win32-x64)
Terminal: Git Bash / Windows Terminal, interactive CLI
Not reproduced in headless or the VSCode extension (consistent with the original report)

Showing cached comments. Read the full discussion on GitHub ↗