Built-in tools and skills intermittently absent from session context (TaskCreate/TodoWrite 'exists but is not enabled')

Status Open
Reported on v2.1.216
Maintainer reply None cached
Activity 1 comment · opened Jul 21, 2026

Summary

Built-in tools and skills are intermittently missing from the session
tool context. In one session the task-list tools (TaskCreate,
TodoWrite) are absent and every call fails with "exists but is not
enabled in this context", so the Ctrl-T task panel cannot be populated
at all. In a session the previous day, the inverse happened with a
built-in skill: /code-review was absent from the session's
available-skills listing yet invoking it via the Skill tool worked.

Environment

  • Claude Code 2.1.216, macOS 26.5.2 (darwin), model claude-fable-5
  • The affected session has the deferred-tools mechanism active

(ToolSearch loads tool schemas on demand), in case that interacts

Incident 1: task tools disabled (2026-07-21)

In a normal interactive session:

  1. ToolSearch over the deferred-tool catalog finds TaskOutput and

TaskStop but no TaskCreate, TaskUpdate, or TodoWrite
(tried exact-name select and keyword searches).

  1. Calling TaskCreate directly returns:

Error: No such tool available: TaskCreate. TaskCreate exists but
is not enabled in this context. Use one of the available tools
instead.

  1. TodoWrite fails identically.
  2. Quitting the CLI and resuming the same session (--resume) changes

nothing: same errors, so the disablement appears to travel with the
resumed conversation context rather than the fresh process.

  1. No permissions/deny rules in user or project settings

(settings.json / settings.local.json) mention these tools.

Effect: the model cannot mirror a plan's to-dos into the task list, so
the Ctrl-T panel stays empty for the whole session. The same tools
worked on this machine as recently as 2026-07-09.

Incident 2: built-in skill missing from the listing (2026-07-20)

In a session the previous day, the built-in code-review skill did
not appear in the session's available-skills listing, but invoking it
through the Skill tool succeeded anyway. So the listing and the
actually-available surface disagree in both directions: incident 1 is
listed-nowhere-and-disabled, incident 2 is unlisted-but-works.

Expected

Built-in tools and skills present in a session's context should match
what is actually invocable, and the task-list tools should be
available in ordinary interactive sessions (or, if intentionally
disabled, the reason should be surfaced somewhere user-visible).

Actual

Availability drifts per session with no user-visible cause, and a
resumed session inherits the drift.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗