irisandClaude Opus 5
6119926a4d
The last commit left renaming out on the grounds that the name is persisted and listed whether or not a process hears about it. That was wrong, and Iris said so: Claude Code keeps its own copy of the name, that copy is what its session picker shows and what other agents read when they list sessions, and a session is only ever *given* a name at birth -- every later start is a `--resume`, which passes no `--name`. So a rename that reached no process left the two lists disagreeing permanently, with this app's the only one that had moved. The cost of a resume buys the one thing renaming is for. It stays `rename_session` rather than becoming a command like the rest, because the name is persisted and listed as well as forwarded and that is one operation. The save happens first and the lock is dropped before the telling, so a failure to start reports that the telling failed rather than the rename, which by then has already happened. `LiveSession::run_command` went with it. It read `shared.status` and that read is exactly what a just-started session cannot be judged by, so every caller now goes through the manager -- which is also what the four tests that used it were standing in for. Verified against a stand-in CLI that echoes its stdin: a session reporting `exited` was renamed, the process started with `--resume`, and the CLI received `/rename after the restart` on stdin. The list shows the new name and the session reports idle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>