Task tools missing in interactive sessions on Opus but present in headless -p; Haiku unaffected (v2.1.218, win32-x64)

Status Closed — duplicate
Maintainer reply None cached
Activity 2 comments · opened Jul 23, 2026 · closed Aug 15, 2026

Summary

TaskCreate, TaskUpdate, TaskGet, and TaskList never load in interactive sessions on claude-opus-4-8, so no todo list ever renders. The same four tools load and work correctly in headless -p mode on the same machine, account, and model. They also work in interactive mode on claude-haiku-4-5-20251001. TaskOutput and TaskStop, from the same family, are present in all cases.

Environment

  • v2.1.218, commit bce61b433bc3
  • win32-x64, npm-global install
  • claude doctor: no installation issues found

Reproduction

Interactive, Opus — broken:

claude --model claude-opus-4-8
> Run ToolSearch with query select:TaskCreate,TaskList

Result: No matching deferred tools found

Interactive, Haiku — works:

claude --model claude-haiku-4-5-20251001
> Run ToolSearch with query select:TaskCreate,TaskList

Result: TaskCreate and TaskList schemas load. A follow-up request to create a three-item task list and mark the first complete renders correctly.

Headless, Opus — works:

claude -p --model claude-opus-4-8 --output-format stream-json --verbose "Create a task list with three items: read the project files, summarize the structure, list any TODO comments found. Then work through them, marking each complete as you go."

The init block lists all four tools in the session roster:

"tools":[..., "TaskCreate","TaskGet","TaskList","TaskOutput","TaskStop","TaskUpdate", ...]

ToolSearch returns tool_reference entries for TaskCreate, TaskUpdate, TaskList. Three TaskCreate calls succeed. TaskUpdate transitions task #1 from pending to in_progress.

Same machine, same account, same model in the first and third cases.

Ruled out

  • CLAUDE_CODE_ENABLE_TASKS is unset. The binary gate is ZD(){ if(Z.CLAUDE_CODE_ENABLE_TASKS===false) return false; return true }, so unset means enabled. Explicitly setting it to 1 changes nothing.
  • No settings files. Tested with ~/.claude/settings.json renamed away, no project-level .claude/settings.json or settings.local.json, and no C:\ProgramData\ClaudeCode\managed-settings.json.
  • No plugins. Tested with the only installed plugin disabled.
  • No --tools flag.
  • ~/.claude.json contains only hasSeenTasksHint and hasUsedBackgroundTask, both cosmetic.
  • The tools exist in the build. bin/claude.exe contains the strings TaskCreate, TaskUpdate, TaskGet, TaskList, plus TaskCreateInput, TaskGetInput, TaskUpdateInput, and TaskListInput interfaces in sdk-tools.d.ts. All four register together as ZD()?[kSd,PSd,NSd,jSd]:[].

Likely cause, with one gap

All four tools gate on isEnabled(){ return ZD() && !Yee() }. Yee() reads feature flag tengu_vellum_ash, cached locally as ["claude-opus-4-8","claude-sonnet-5","claude-fable-5"]. That list matches the affected models exactly, and Haiku's absence from it matches Haiku working.

The gap: headless -p on claude-opus-4-8 loads the tools despite the model being in that list. So the flag alone does not account for the behavior, and the interactive versus headless difference appears to be the real anomaly.

Also note: the same flag disables legacy TodoWrite via isEnabled(){ return !ZD() && !Yee() }, so affected models lose both paths and get no fallback list at all rather than degrading to the old behavior.

Questions

  1. Is the tengu_vellum_ash gating intentional for these models?
  2. Why does headless -p bypass it on the same model?
  3. Is there any supported way to restore the tools in interactive Opus sessions? Both local override paths appear dead in this build: kZt() is function kZt(){return}, and the CLAUDE_INTERNAL_FC_OVERRIDES parser in A6r() sits below an unconditional return.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗