Skip to main content
On the models listed under Model availability, Claude tracks multi-step work without a written todo list, and Claude Code leaves the task-tracking tools out of sessions by default. You don’t need anything on this page for Claude to work through multi-step tasks on those models. In a session that has the task-tracking tools, Claude keeps a written todo list, updating each item’s status as it works. You see each change in the message stream as a structured tool call. Opt a session in only when your application reads those tool calls, whether to log task activity or to render its own progress display.

Model availability

On TypeScript Agent SDK 0.3.233 and later, or Python Agent SDK 0.2.139 and later, the following tools aren’t available on Opus 4.8, Sonnet 5, Fable 5, Mythos 5, or later versions of those families unless you opt in:
  • TodoWrite
  • TaskCreate
  • TaskGet
  • TaskUpdate
  • TaskList
On other models, Claude Code provides the Task tools by default and TodoWrite only when you set CLAUDE_CODE_ENABLE_TASKS=0.
On the listed models, unless you opt a session in, you see no tool_use blocks for the tools in the message stream. The Agent SDK applies these defaults through the Claude Code binary that it bundles. If you point pathToClaudeCodeExecutable (TypeScript) or cli_path (Python) at your own Claude Code install, you get whichever tools that install provides, under its own defaults. To see the exact set in a running session, check which tools are available. To opt a session in, do one of the following:
  • Name one of the tools in the allowedTools (TypeScript) or allowed_tools (Python) option
  • List the tools in the tools option, which restricts the session’s built-in tools to the ones it names. Include the tools you want alongside the other built-in tools you use
  • Set CLAUDE_CODE_ENABLE_TODO_TOOLS=1 in the env option, as the examples on this page do. In TypeScript, env replaces the subprocess environment, so spread ...process.env to keep inherited variables. In Python, env is merged on top of the inherited environment

Todo lifecycle

Claude moves each todo through a predictable lifecycle:
  1. Created: Claude adds the todo as pending when it identifies a task
  2. Activated: Claude sets the todo to in_progress when it starts the work
  3. Completed: Claude marks it completed when the task finishes successfully
  4. Removed: Claude deletes a todo it no longer needs by setting status: "deleted" in a TaskUpdate call

When Claude creates todos

In a session that has the task-tracking tools, Claude creates todos for most multi-step work, such as:
  • Complex multi-step tasks requiring three or more distinct actions
  • User-provided task lists when multiple items are mentioned
  • Longer operations that benefit from progress tracking
  • Explicit requests when users ask for todo organization
Claude may skip todos for very short or single-step requests.

Examples

Before running these examples, install the Claude Agent SDK by following the quickstart. Every example on this page shares the same permission setup and exit behavior:
  • Permission mode: the example prompts ask Claude to do real work on a project, so each example sets permissionMode: "acceptEdits" (TypeScript) or permission_mode="acceptEdits" (Python) to auto-approve the file edits that work produces. See Permission modes for the alternatives.
  • Turn limit: each example runs until the agent finishes and yields its final result message. If a session reaches its turn limit first, that result message has the error_max_turns subtype. Check subtype to detect that ending.
  • Error handling: these examples use single-shot query() calls. After yielding an error_max_turns result, query() raises an error that includes Reached maximum number of turns. Each example wraps its loop in a try block to exit cleanly when that happens. See Handle the result for the result subtypes.
The task system messages, SDKTaskNotificationMessage (TypeScript) or TaskNotificationMessage (Python) among them, report background tasks such as backgrounded commands and subagents. In the message stream, you see todo activity as tool_use blocks in the assistant messages.

Monitor todo changes

The following example watches the assistant stream for TaskCreate and TaskUpdate tool_use blocks and prints a + line with each new task’s subject and an update line with each status change’s task ID and new status. Use this shape when you want a log of task activity rather than a rendered display. The + lines don’t include the assigned IDs, so this log can’t match updates back to their creates. To keep that correlation, capture the IDs as Display progress in real time does. The streamed tool_use input is the raw shape the model emitted. Claude Code repairs some close-but-incorrect key names before execution, mapping id or task_id to taskId and active_form to activeForm, but that repair is not reflected in the stream. Read TaskUpdate input fields defensively, as both examples on this page do, rather than assuming the canonical name is always present.

Display progress in real time

The following example watches the assistant stream for TaskCreate and TaskUpdate tool_use blocks and keeps a map of tasks keyed by task ID in a TaskTracker class, rerendering a progress summary on every change. The summary counts completed and in-progress tasks and shows each active item’s activeForm label in place of its subject. Use this shape when your application maintains a progress display instead of logging each event. The assigned task ID isn’t in the TaskCreate input. Claude Code delivers each tool’s structured output on the user message that carries its tool_result block, in the tool_use_result field. For TaskCreate, that object is documented for TypeScript as TaskCreateOutput under Tool Output Types, and in Python the field is a plain dict of the same shape. The tracker pairs each tool_result block with its tool_use call by tool_use_id and reads task.id from the paired message’s tool_use_result. Claude can read the list back with TaskList and one task’s full details with TaskGet.