Named headless (-p) sessions should be visible in the /resume picker and resumable by name interactively

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

I chain long autonomous sessions overnight with a wrapper script: each claude -p "<start prompt>" --name S11 run works for an hour or more, commits its results, and the wrapper launches the next session. The next morning I want to open /resume and review what each session actually did.

I can't: sessions created headlessly never appear in the /resume picker and cannot be found by interactive claude --resume <name>, even when explicitly named with --name. These overnight runs are my most substantial sessions, yet they are the only ones invisible in my session history -- while every trivial interactive Q&A session is listed. As scheduled/overnight agent runs become more common, more of a user's important history lands on the invisible side of this filter.

What I observed (Claude Code v2.1.208, Windows 11):

1. claude -p "..." --name my-session runs fine; the transcript is saved to ~/.claude/projects/<project>/<id>.jsonl and contains the custom-title record.
2. The session never appears in the /resume picker.
3. Interactive claude --resume my-session fails with No sessions match "my-session", while headless claude -p "..." --resume my-session finds and resumes it correctly. Same store, same name, different lookup scope, and the error message gives no hint why.
4. Resuming by explicit session ID interactively works, and messages added that way are stamped entrypoint:"cli" -- but the session STILL never appears in the picker afterwards. Visibility appears to be decided solely by the creation entrypoint (sdk-cli vs cli).
5. The picker exclusion of -p/SDK sessions is documented behaviour (see #42311, closed as completed) -- so this is a feature request for a deliberate opt-in, not a bug report against the default.

Proposed Solution

Ideal experience: when I pass --name to a headless session, that session appears in the /resume picker under that name, exactly like an interactive session -- --name is about as clear a signal as exists that a human intends to come back to it. The morning after an overnight chain I would open /resume, see "S11", "S12", "S13" listed with their sizes and timestamps, and open any of them to read the full transcript.

Equally acceptable forms of the same opt-in:

• an explicit flag, e.g. claude -p --track;
• a picker filter toggle ("show headless sessions").

Independently of the picker: interactive claude --resume <name> should find any named session (or explain why it was excluded), matching the behaviour of headless claude -p --resume <name>, which already finds it.

Keeping unnamed programmatic runs out of the picker by default is sensible -- CI and scripted invocations would flood it. The request is only for a deliberate opt-in.

Alternative Solutions

Current workaround (works, but is a ritual): I discovered that picker visibility is decided at session CREATION, and that an interactively-born session STAYS visible after headless work is appended to it. So before launching a chain I pre-create named stub sessions in the REPL (claude, /rename S11, one throwaway message, /exit), and the wrapper drives each session's entire workload into its stub via headless claude -p "..." --resume S11. The sessions then appear in the picker with the real work inside.

Also considered/tried:

• Naming at launch with --name: accepted, resumable by name headlessly, but invisible in the picker and invisible to interactive resume-by-name.
• Retroactive promotion (interactively resuming a headless-born session by ID and adding messages): does not make it appear in the picker.
• Maintaining my own index file mapping session names to IDs, and resuming by ID: functional, but it reimplements the picker outside the product.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

1. Overnight autonomous chains: a wrapper script runs several multi-hour claude -p "<start prompt>" --name S11 sessions back to back; next morning the user opens /resume to audit what each session did. Currently the most substantial sessions in the project are the only ones absent from the picker.

1. Scheduled agents: a nightly cron/Task Scheduler job runs claude -p --name nightly-refactor-0715; a week later the user wants to open Tuesday's run to see why a change was made. Today that requires having externally recorded the session id.

1. Team/CI batch runs: a batch of named -p sessions (one per module) performs a large migration; a reviewer wants to open individual sessions afterwards to inspect the agent's reasoning on specific modules, without maintaining a separate name-to-id index.

1. Context management is the very reason for the pattern: running each unit of work as a fresh claude -p session (instead of one long interactive session with repeated /clear or auto-compaction) gives every session a clean context window -- no compaction events mid-work, no tokens spent re-establishing state, state carried in files rather than conversation history. Headless chaining is thus the natural best practice for long-running agentic work, but adopting it currently means those sessions vanish from /resume. Users should not have to choose between context hygiene and a browsable session history.

Additional Context

Claude Code v2.1.208, Windows 11, PowerShell wrapper chaining claude -p runs.