[FEATURE] A current task for the task tools, with parent tasks and descriptions people can see

Status Open
Reported on v2.1.296
Maintainer reply None cached
Activity 0 comments · opened Oct 13, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

The task tools track a session's work, but nothing says which task the session is on.

  • Several tasks can be in progress at once.
  • Nothing tells the task being worked apart from one waiting on a subagent, a background command or the user.
  • Compaction keeps the tasks, but not the model's memory of which one it was on.
  • A task's description is the natural place for the user's words, the files and the decisions so far.
  • Neither the person nor TaskList's result ever shows it.
  • A task cannot hold subtasks, which #83614 asked for before it was closed as not planned.

Proposed Solution

Let the task list hold where a session is, so a fresh session or a person can pick up any task from the list alone.

  • One current task: the one in-progress task that waits on nobody.
  • Starting a second task is refused until the current one is completed, paused with a reason, or marked as waiting on someone.
  • A parent per task: a task may name its parent.
  • A subtask of the current task may start, and hands current back to its parent when it completes.
  • A parent with open subtasks cannot complete.
  • Descriptions people can see: the task list view shows each task's description.
  • Creating a task without a description is refused.
  • The model gets it back after compaction: TaskList's result names the current task, each task's parent, and who each task waits on.

We built this as a mod on Claude Code 2.1.296, which can serve as the sketch:

  • TaskCreate and TaskUpdate hooks judge each call against the task files, and deny it with the reason and what would pass.
  • The state rides in TaskUpdate's free metadata, as the keys parent, waitingOn and pausedBecause.
  • A TaskList hook appends the current task, the parents and the waits to the result's context.
  • A /task-tree command opens a pane with the open tasks as a tree, the current one marked, each with its description.
  • A band above the prompt names the current task.

The mod reads ~/.claude/tasks/<list id>/*.json itself, since the tools return no metadata.
That layout is internal, so a built-in version would remove the mod's riskiest part.

Alternative Solutions

  • Keep it in a mod. It works, but it depends on the task files' internal layout.
  • Keep a TODO file in the repository. It drifts from the tasks the model actually works from.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

  1. The user asks for a feature, and the session creates a task holding the user's words in its description.
  2. The session hands a subtask to a subagent, marks the parent as waiting on it, and starts an unrelated task.
  3. Compaction runs, and TaskList tells the model which task is current and what waits on whom.
  4. The person runs /task-tree and sees where the session is, without scrolling the transcript.

Additional Context

Drafted by Claude Opus 5.5 in Claude Code, for Marcos Pereira, who decided to file it.
Happy to share the mod's source.

View original on GitHub ↗