›_ Claude Code Issues
Claude Code Issues / #80213

Structured Task tools (TaskCreate/TaskList/TaskGet/TaskUpdate) unavailable in a top-level CLI session on v2.1.206 despite CLAUDE_CODE_ENABLE_TASKS=true

Status Fixed / completed
Reported on v2.1.206
Maintainer reply None cached
Activity 7 comments · opened Jul 22, 2026 · closed Jul 23, 2026

Summary

In a top-level Claude Code CLI session on v2.1.206, the structured Task tools (TaskCreate, TaskList, TaskGet, TaskUpdate) are not available — and neither is the legacy TodoWrite. The same account, same flag, same version exposes all four in a Claude Code Desktop session. CLAUDE_CODE_ENABLE_TASKS=true is set and verified live in the process environment.

Per the Task tools docs they are default-on since v2.1.142, so I expected them to be present.

Environment

| | |
|---|---|
| Claude Code version | 2.1.206 |
| CLAUDE_CODE_ENTRYPOINT | cli |
| CLAUDE_CODE_ENABLE_TASKS | true (live in process env) |
| OS | Windows 11 |
| Session type | top-level (see below) |

Expected

TaskCreate / TaskList / TaskGet / TaskUpdate available (default-on ≥ 2.1.142), or legacy TodoWrite if the flag were disabling them.

Actual

None of them are present. A tool search for TaskCreate,TaskUpdate,TaskGet,TaskList,TodoWrite returns nothing; a keyword search returns only unrelated tools. So neither the new family nor the legacy TodoWrite is registered.

Ruled out

  • Config value/type — flag is a string "true" in settings.json env and arrives correctly in the process environment.
  • Version — 2.1.206 is well past the 2.1.142 default-on threshold.
  • Nested/child session — this is genuinely top-level: the process tree shows a single claude.exe launched directly from cmd.exe → Windows Terminal, with no parent claude process. (CLAUDE_CODE_CHILD_SESSION=1 does appear in the environment of shells the session spawns, but it is not persisted at User/Machine scope — it is the marker Claude Code stamps onto its subprocess environment, not a signal that this session is nested.)

Possibly relevant

This session also exposes a non-standard / expanded tool registry and additional model options beyond the stock CLI set, which may indicate a non-default build channel. That could be the reason the todo-tool family is swapped out — in which case this may be expected rather than a regression. Happy to share the specific tool/model identifiers privately if useful for diagnosis.

Question

Is the absence of the Task/TodoWrite tool family expected for this build/configuration, or is it an unintended registration gap? If expected, a docs note on when the family is not registered would help.

View original on GitHub ↗

5 Comments

rubrical-worker · 1 month ago

Duplicate of #80210

DrumRobot · 1 month ago

Reproduced this outside Windows too — confirms it's not OS/build-specific.

macOS, CLI top-level session wrapped by a terminal multiplexer (cmux/Ghostty-based):

  • Claude Code v2.1.206
  • CLAUDE_CODE_ENABLE_TASKS=true confirmed present in the live process environment
  • TaskCreate and TaskList calls both return: Error: No such tool available: <name>. <name> exists but is not enabled in this context.
  • Ruled out hook interference on my end — no PreToolUse hook in my settings.json exact-matches these tool names (checked the hook source directly; it only fires on the literal Agent/Task tool names, not Task* prefixed ones)
  • ~/.claude.json has a cachedGrowthBookFeaturesAt timestamp, consistent with this being a GrowthBook feature-flag evaluation gap on the CLI code path specifically (the original report notes Desktop sessions on the same account/version work fine)

Also independently reproduced on Windows inside Zellij (a different terminal multiplexer) — same symptom. So this doesn't look tied to a specific terminal wrapper (cmux vs Zellij) either; it's consistently CLI-session-scoped regardless of platform or terminal multiplexer.

rubrical-worker · 1 month ago

I just discovered this and it worked for me:

Try this (or equivalent for your environment):

"env": {
"CLAUDE_CODE_ENABLE_TASKS": "true",
"ENABLE_TOOL_SEARCH": "false"
},

Task tracking
TaskCreate, TaskList, TaskGet, TaskUpdate — present and verified working this session

rubrical-worker · 1 month ago

Closing as I discovered the fix.

rubrical-worker · 1 month ago
Reproduced this outside Windows too — confirms it's not OS/build-specific. macOS, CLI top-level session wrapped by a terminal multiplexer (cmux/Ghostty-based): Claude Code v2.1.206 CLAUDE_CODE_ENABLE_TASKS=true confirmed present in the live process environment TaskCreate and TaskList calls both return: Error: No such tool available: <name>. <name> exists but is not enabled in this context. Ruled out hook interference on my end — no PreToolUse hook in my settings.json exact-matches these tool names (checked the hook source directly; it only fires on the literal Agent/Task tool names, not Task* prefixed ones) * ~/.claude.json has a cachedGrowthBookFeaturesAt timestamp, consistent with this being a GrowthBook feature-flag evaluation gap on the CLI code path specifically (the original report notes Desktop sessions on the same account/version work fine) Also independently reproduced on Windows inside Zellij (a different terminal multiplexer) — same symptom. So this doesn't look tied to a specific terminal wrapper (cmux vs Zellij) either; it's consistently CLI-session-scoped regardless of platform or terminal multiplexer.

I just discovered this and it worked for me:

Try this (or equivalent for your environment):

"env": {
"CLAUDE_CODE_ENABLE_TASKS": "true",
"ENABLE_TOOL_SEARCH": "false"
},

Task tracking
TaskCreate, TaskList, TaskGet, TaskUpdate — present and verified working this session

Showing cached comments. Read the full discussion on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Windows & WSL problems

Browse all Claude Code issue topics →