Plan Mode: locally-saved plan drafts (~/.claude/plans/*.md) get garbage filenames derived from system-reminder/environment text instead of the plan's title

Summary

Locally-saved Plan Mode drafts under ~/.claude/plans/*.md are sometimes given a filename derived from injected system/environment text instead of the plan's actual title. The plan content itself is unaffected and correct — this is purely a filename-generation bug, but the resulting filenames are meaningless and make the directory unusable for finding a plan later.

Environment

• Platform: Windows 11, PowerShell
• Claude Code CLI, most recent version as of 2026-09-24

Observed behavior

Filenames in ~/.claude/plans/ normally look like a slug of the user's own opening message, e.g.:

• clark-do-a-full-<random-codename>.md
• create-data-dictionaries-for-<random-codename>.md

These are fine — clearly derived from real, human-typed text.

But a recurring subset of files instead have filenames slugified from harness-injected text that was never part of any human message, e.g. (real examples, generalized):

• system-reminder-you-are-operating-<random-codename>.md
• system-reminder-you-are-operating-<random-codename>-agent-<16-hex-chars>.md
• today-is-2026-0x-xx-here-<random-codename>.md
• this-directory-holds-a-<random-codename>.md
• working-in-<os-name>-<random-codename>.md

I opened several of these and confirmed: the actual Markdown content is a completely normal, well-formed implementation plan with its own correct # Title heading — totally unrelated to the filename. For example, a file named system-reminder-you-are-operating-<codename>.md had real content starting with # Fix: <some real feature> — <some real bug>, with no system-reminder text anywhere inside it. So the plan-saving code has access to the right title, it's just not what gets used for the filename in these cases.

Reproduction pattern (best guess)

This appears to happen specifically when the turn that triggers the plan save does not begin with human-authored text — e.g.:

• a dispatched subagent whose prompt is constructed entirely by its parent/orchestrator, with harness-injected context (a <system-reminder> block about the working directory/worktree, a "today's date is ..." reminder, an environment-info block, etc.) appearing before any task-specific text;
• possibly also a resumed or non-interactively-triggered session with no fresh human message in that turn.

In those cases, the filename-slug generator appears to fall back to grabbing the first several words of that injected block (e.g. literally "you are operating in a git worktree...", complete with a worktree/session codename that happens to appear later in the same block) rather than the plan document's own title/H1.

The -agent-<16-hex> suffix

Some of these bad-slug files come in pairs: one with a -agent-<16 hex chars> suffix, and a nearly-identical (sometimes byte-identical, sometimes a lightly revised re-save a few minutes later) sibling without the suffix. The <16 hex chars> format matches the internal subagent-transcript ID format used elsewhere by the CLI (agent-<hash>.jsonl under a session's subagents/ folder). This suggests:

1. A dispatched subagent (one with its own Plan Mode access) saves its own draft locally, tagging the filename with its own agent ID to avoid colliding with the parent's file.
2. The parent session (or the same subagent after revision) later re-saves a cleaned-up version under the same bad slug, minus the agent-id suffix.

Both saves inherit the same wrong slug-source bug.

Impact

• ~/.claude/plans/ accumulates files whose names give no indication of what's inside, making the directory impossible to browse/search by filename.
• Anyone with a workflow that syncs/archives these plan files elsewhere (e.g. a personal script that copies them into a notes vault, keyed by a title-derived name) inherits the garbage name too.
• Not data-destructive — the plan content is always intact and correct, and this is override-able by manually renaming, but it defeats the purpose of an auto-generated descriptive filename.

Expected behavior

The filename slug should always be derived from either (a) the plan document's own title/first H1 heading (which is present and correct in every affected file I checked), or (b) the real human-authored task description that led to the plan, and should never be sourced from <system-reminder> or other harness-injected context text.

Additional notes

• This is not a one-off — I found dozens of historical examples of the same bug (different injected-text sources each time) going back through git history in a ~/.claude/plans/ directory that's tracked in a personal dotfiles repo, alongside many correctly-named sibling files from the same time period. So the bug is intermittent/conditional, not universal — it seems tied to the specific circumstance described above (turn beginning with no human-authored text) rather than being broken all the time.
• Happy to provide further (sanitized) examples if useful, but I'm not including real file/plan content here since it references private project details.