[BUG] Scheduled task session names no longer reflect description field — date prefixes stopped appearing in sidebar

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Description
Scheduled task session names in the Cowork sidebar used to display the task's description field as the session title. This allowed tasks to stamp their own description with a date prefix (e.g., "Apr 3 – Daily briefing") at the end of each run via update_scheduled_task, so the next session created for that task would appear in the sidebar with the run date visible at a glance.
As of ~April 5, all new scheduled task sessions display only the taskId converted to title case (e.g., daily-briefing → "Daily briefing") regardless of what the description field is set to. Updating description via update_scheduled_task succeeds (the field stores correctly and is returned by list_scheduled_tasks) but has no effect on the session name shown in the sidebar.

What Should Happen?

Expected Behavior
The session name in the sidebar should reflect the task's current description field at the time the session is created — matching the behavior observed on April 3-4 where sessions were correctly named things like:

"Apr 3 – Daily briefing"
"Apr 4 – Weekly finance snapshot"
"Apr 3 – Travel booking monitor"

Error Messages/Logs

# [BUG] Scheduled task session names no longer reflect `description` field — date prefixes stopped appearing in sidebar

## Environment
- **Platform:** Windows (Claude Desktop / Cowork mode)
- **Date regression observed:** ~April 5, 2026
- **Last known working:** April 3-4, 2026

## Description

Scheduled task session names in the Cowork sidebar **used to** display the task's `description` field as the session title. This allowed tasks to stamp their own description with a date prefix (e.g., `"Apr 3 – Daily briefing"`) at the end of each run via `update_scheduled_task`, so the next session created for that task would appear in the sidebar with the run date visible at a glance.

As of ~April 5, all new scheduled task sessions display only the **taskId converted to title case** (e.g., `daily-briefing` → "Daily briefing") regardless of what the `description` field is set to. Updating `description` via `update_scheduled_task` succeeds (the field stores correctly and is returned by `list_scheduled_tasks`) but has **no effect on the session name shown in the sidebar**.

## Steps to Reproduce

1. Create a scheduled task:
   
   create_scheduled_task(
     taskId: "test-task",
     description: "Apr 13 – Test task",
     prompt: "Say hello",
     cronExpression: "0 9 * * *"
   )
   

2. Let the task run (or trigger manually).

3. Observe the sidebar: the session is named **"Test task"**, not **"Apr 13 – Test task"**.

4. Call `update_scheduled_task(taskId: "test-task", description: "Apr 14 – Test task")`.

5. Let the task run again. The new session is still named **"Test task"**.

6. Call `list_scheduled_tasks` — the description field correctly shows `"Apr 14 – Test task"`, confirming the update was stored. It's just not used for the session name.

## Expected Behavior

The session name in the sidebar should reflect the task's current `description` field at the time the session is created — matching the behavior observed on April 3-4 where sessions were correctly named things like:
- "Apr 3 – Daily briefing"
- "Apr 4 – Weekly finance snapshot"
- "Apr 3 – Travel booking monitor"

## Actual Behavior

All sessions created after ~April 5 show only the taskId-derived name:
- "Daily briefing" (instead of "Apr 12 – Daily briefing")
- "Travel booking monitor" (instead of "Apr 12 – Travel booking monitor")
- "Events concierge" (instead of "Apr 12 – Events concierge")

## Evidence

Session list showing the regression — old sessions have dates, new ones don't:


# Old sessions (working correctly):
"Apr 4 – Daily briefing"
"Apr 4 – Daily shopping price check"
"Apr 4 – Aiwalia email scanner"
"Apr 3 – Daily briefing"
"Apr 3 – Daily shopping price check"
"Apr 3 – Travel booking monitor"

# New sessions (broken — no dates):
"Daily briefing"
"Daily shopping price check"
"Events concierge"
"Travel booking monitor"
"Aiwalia email scanner"


Meanwhile, `list_scheduled_tasks` confirms the descriptions ARE stored correctly:

{"taskId": "daily-briefing", "description": "Apr 12 – Daily briefing"}
{"taskId": "events-concierge", "description": "Apr 12 – Events concierge"}
{"taskId": "travel-booking-monitor", "description": "Apr 12 – Travel booking monitor"}


## Impact

For users with multiple recurring scheduled tasks (I have 9 active), the sidebar becomes a wall of identical names grouped under each task — e.g., six sessions all named "Daily briefing" with no way to tell which day each one ran without clicking into it. The date-prefix pattern was a clean workaround that gave at-a-glance visibility into run history.

## Possibly Related

- Issue #34667 (SKILL.md not accessible from session VM) — if the SKILL.md frontmatter is what drives session naming, a change in how SKILL.md is read could explain this regression.

## Suggested Fix

Either:
1. **Restore the previous behavior** where the task `description` field is used as the session name.
2. **Automatically include the run date** in session names for scheduled tasks (e.g., "Apr 13 – Daily briefing") as a platform feature, since this is a common need for anyone with recurring tasks.

Steps to Reproduce

Steps to Reproduce

Create a scheduled task:

create_scheduled_task(
taskId: "test-task",
description: "Apr 13 – Test task",
prompt: "Say hello",
cronExpression: "0 9 *"
)

Let the task run (or trigger manually).
Observe the sidebar: the session is named "Test task", not "Apr 13 – Test task".
Call update_scheduled_task(taskId: "test-task", description: "Apr 14 – Test task").
Let the task run again. The new session is still named "Test task".
Call list_scheduled_tasks — the description field correctly shows "Apr 14 – Test task", confirming the update was stored. It's just not used for the session name.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code version 2.1.92

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_