/clear cannot name the new conversation, and a flag-shaped argument becomes the title silently

Status Open
Reported on v2.1.257
Maintainer reply None cached
Activity 0 comments · opened Sep 1, 2026

Summary

/clear <name> names the conversation you are leaving. There is no argument form that names the conversation you are starting — that still takes two commands, /rename X then /clear. And because the positional argument accepts any string, a flag-shaped attempt is silently swallowed as a title rather than rejected.

Two asks: an argument to name the new conversation, and an error on an unrecognised flag.

What I measured

Claude Code 2.1.257, Linux. Three runs, each checking claude agents --json and the on-disk custom-title.json for both session ids.

1. /clear fleetname-test — behaves exactly as documented. The outgoing session c9bb26e6 got {"customTitle":"fleetname-test"}; the new session 34d02abf started unnamed and fell back to the auto-generated tmp-7d. The sessions page says this plainly: "To name the conversation you're leaving instead, pass the name, as in /clear release-prep; the new conversation then starts unnamed." No complaint here — the documentation is accurate and the behaviour is sensible.

2. /rename carried-name then /clear — works, and is the current answer. The new session 2b69af0b carried carried-name, matching "the new conversation keeps a name you set with --name or /rename".

3. /clear --name flagtest — this is the defect. No error, no warning. The outgoing session 7b075b18 was given the literal title --name flagtest, and the new session started unnamed as tmp-d9. A user who reaches for the CLI's own --name spelling gets a session in their /resume picker titled --name flagtest and no indication anything went wrong.

Requests

1. A one-command way to name the new conversation. /clear --name <name> is the natural spelling, since claude --name already means exactly this and users will try it first — run 3 shows they currently get a silently mis-titled session for the attempt. --as or --next would do equally well. The bare positional keeps its current meaning, so nothing breaks.

Why it matters beyond one keystroke: with several sessions open in a multiplexer or the agents view, the name is how a session is identified, and /clear is precisely the moment its identity changes — the old task is finished, a new one begins. The name that survives the clear is then the previous task's name, which is worse than no name because it is confidently wrong. Doing it in the right order works, but "rename before you clear" is a discipline the tool could simply not require.

2. Reject an unrecognised leading-dash argument. Whatever is decided about (1), /clear --name X titling a session --name X is wrong under either design. An argument starting with - that is not a recognised flag should error rather than become a title.

Environment

Claude Code 2.1.257, Linux. Related: #77890 (name persistence across /clear, fixed in 2.1.111); the /clear <name> outgoing-label behaviour dates to 2.1.136.

View original on GitHub ↗