[Bug] Session name not updated when subsequent plans created in same session

Bug Description
Bug Report: Session Name Derived from First Plan, Not Session Purpose

From: Jordan Dea-Mattson
GitHub: @jordan-of (OrdinaryFolk), @jordandm (personal)
Email: jordan-of@users.noreply.github.com
Related: #36909 (Session naming and state indicators — feature request for editable session names)

Problem

Claude Code's session name is set by the plan-capture hook when the first plan is created via ExitPlanMode. Once set, it never changes — even if the session goes on to do completely different
work.

In practice, a session launched to build "tool telemetry and permission gap analysis" ended up named tool-telemetry-permission-gap because that was the first plan created. The session then
continued for hours doing git hygiene hardening, transcript analysis, quality gate design, and feedback drafting — none of which are reflected in the name. The terminal tab still says
tool-telemetry-permission-gap.

This creates real confusion when running multiple concurrent sessions. The tab name tells you what the session started doing, not what it's actually doing. In a workflow with 4-5 active sessions,
misleading names cost time switching between tabs to find the right one.

Root Cause

The plan-capture hook (plan-capture.sh) fires on ExitPlanMode and derives the session name from the plan's title slug. The first plan captured sets the terminal title via the session name.
Subsequent plans in the same session don't update it — the name is write-once.

Expected Behavior

At minimum:

• The session name should update when a new plan is created, reflecting the most recent work context
• Or better: the session name should be independent of plans entirely, and settable by the user (per #36909)

The current behavior makes the session name a historical artifact of the first thing you happened to plan, not a description of what the session is doing. For long-running sessions that span
multiple tasks (which is the norm with conversation context preservation), this is actively misleading.

Workaround

None currently available. There is no command to rename a session, no flag to set the name on resume, and the plan-capture hook has no mechanism to update an existing session name. This is one of
the motivations behind the feature request in #36909.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.81
• Feedback ID: 569a67b3-f4f2-4ed0-a507-69b3cb4f77a7

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/jordan_of/.local/share/claude/versions/2.1.81 (expected in multi-process scenarios)\n    at TET (/$bunfs/root/src/entrypoints/cli.js:2724:2174)\n    at fgq (/$bunfs/root/src/entrypoints/cli.js:2724:1318)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-21T03:43:37.846Z"}]