[Feature Request] Add status and label classification for sessions in Claude Desktop

Status Closed — not planned
Maintainer reply None cached
Activity 2 comments · opened Mar 7, 2026 · closed Apr 4, 2026

Summary

Add the ability to assign statuses (workflow states) and labels (tags) to Claude Code sessions in Claude Desktop, enabling session-level task management.

Problem

As Claude Desktop evolves into an agentic workspace — with Cowork, background tasks, and multi-session workflows — the number of concurrent sessions per user is growing rapidly. However, the session list remains a flat, chronological view with no way to classify, filter, or group sessions.

This creates friction at two levels:

  1. Session discovery — Finding the right session among dozens requires opening each one. Naming (/name) helps identify sessions, but names don't convey state. "Is this task done? Waiting on someone? Still in progress?" can only be answered by opening the session.
  2. Context switching overhead — Before starting work, users must first locate the session, then recall its state. This overhead compounds with every additional session and becomes a meaningful productivity bottleneck.

These problems will only intensify as agent capabilities grow. More delegation → more sessions → harder to manage. Several existing issues point to the same underlying gap from different angles:

  • #7483 — Users want to tag sessions for easier selection in claude -r
  • #11408 — Users want to name and organize sessions

These requests are symptoms of a missing layer: session-level metadata for workflow management.

Motivation: Why Sessions — Not a Separate Tool

A Claude Code session already accumulates everything relevant to a task: conversation history, execution logs, file changes, links, and decisions. It is the working context.

When tasks are tracked in a separate tool (Jira, Linear, markdown files, or even a mental list), users must constantly cross-reference: find the right session for a task, recall its state, copy results back to the tracker. This overhead scales linearly with the number of concurrent sessions.

The insight is simple: the session already is the task — it just lacks the metadata to be managed as one. Adding status and label support would close this gap, turning the session list into a functional task board with zero additional tooling.

Proposed Solution

Statuses (workflow states)

Allow users to assign a single status to each session from a user-configurable set. Sessions should be filterable and groupable by status in the sidebar.

Example configuration:

| Status | Purpose |
|--------|---------|
| Today | Active work for today |
| Tomorrow | Queued for next work session |
| In Review | Blocked / waiting on external input |
| Completed | Done |
| Cancelled | Abandoned |
| Someday | Low-priority backlog |

Labels (tags)

Allow users to attach one or more labels to a session for cross-cutting categorization:

  • Project identifiers: GitHub, Jira
  • Customer or team names: Customer: Acme, Team: Platform
  • Task types: Research, Implementation, Bug Fix

Natural language control

Allow setting status/labels conversationally within a session:

  • "Mark this as completed"
  • "Add label 'Research'"

Why This Matters for Claude Desktop

Google's Antigravity already ships an Inbox feature with session-level organization. As agentic IDEs become the primary work interface, session management is no longer a nice-to-have — it's infrastructure.

Claude Desktop is uniquely positioned here. With Cowork, background agents, and HITL patterns, users are already running multiple sessions in parallel. The missing piece is the ability to see at a glance which sessions need attention, which are blocked, and which are done — without opening each one.

Prior Art

  • Antigravity (Google) — Inbox with session organization
  • Craft Agents (open-source, Apache 2.0, built on Claude Agent SDK) — Implements configurable statuses and labels for sessions. I've been using this pattern daily and can confirm it works well in practice.

View original on GitHub ↗

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