Skip to content

[Feature]: Allow /rename while a turn is running #427

Open

Description

@TheBaby5

Product or interface

CLI - interactive TUI

Use case and problem

Right now, /rename [title] is blocked while a turn is running:

Stop the running turn before using /rename [title].

That creates unnecessary friction.

A user may suddenly think of the perfect session name while MCode is still doing important work. They should not have to:

wait for the whole task to finish
OR
stop an important running task

just to rename the session.

The rename is only session metadata and should not need to interrupt execution.

BEFORE

running task
↓
user gets a good title idea
↓
/rename blocked ❌
↓
wait for task to finish
↓
rename later / possibly forget

AFTER

running task ───────────────→ keeps running
│
└→ /rename "new title"
↓
title changes ✅

No interruption.
No lost work.
No waiting.

Desired behavior

Allow /rename [title] at any time, including while a turn, tool call, background task, or subagent is running.

Requirements:

  • Rename only the session title/metadata.
  • Do not stop, restart, pause, steer, or alter the active turn.
  • Do not change model context.
  • Do not affect queued messages or background work.
  • Update the TUI title immediately.
  • Persist the new title normally.
  • If a rename happens during execution, it should be completely independent from the running task.

Simple rule:

execution state ≠ session title state

So:

running turn + /rename
→ rename metadata only
→ task continues untouched

Platform

Linux

Alternatives and additional context

Current workaround:

wait until task finishes
→ rename

or

stop task
→ rename
→ lose/interfere with ongoing work

Neither is necessary for a metadata-only operation.

This should be a small UX improvement, but it matters because session naming often happens when the user suddenly gets a clearer idea of what the session has become.

The waiting itself can break that flow or make the user forget the title.

Core goal:

/rename should behave like harmless metadata editing, not like a runtime operation.

Activity

  1. hetaoBackend commented on Oct 13, 2026

    @hetaoBackend
    Collaborator

    Thanks for the report — this is accepted as a feature request, and the /rename restriction while a turn is running is confirmed as current behavior.

    Triage action: moved out of needs-triage and labelled enhancement + tui. It is in the candidate pool for a good first issue task once the change is scoped.

    What we need from you to scope it (please reply with these three points):

    1. Should /rename while a turn is running only rename the session title, or should it also be allowed to change the turn's working title in the transcript?
    2. If a rename happens mid-turn, should the running turn's output be re-titled as well, or only subsequent turns?
    3. Is there a case where you would expect /rename to be rejected even while a turn is running (for example, during an active tool call)?

    We will reply within 48 hours. Note that contribution policy is moving from invitation-only to application-based; if you want to implement this yourself, a fork PR does not require collaborator access — open an issue describing the scope first so we can confirm it is not already being worked on.

  2. joshua-zyy commented on Oct 14, 2026

    @joshua-zyy

    Claiming this one if nobody has it — I have a local implementation and can answer your three scoping questions from the code:

    1. Session title only. There is no separate working-title field on the turn, so a rename writes session metadata (cliService.updateSession({id, title})) and nothing else.
    2. Neither. Already projected output is not re-titled, and later turns are unaffected — a metadata write does not rewrite the transcript projection.
    3. No case needs rejection while a turn is genuinely running, including during an active tool call. I would keep two existing rejections: side conversations (rename stays out of SIDE_MODE_COMMANDS) and "no current session".

    The patch keeps the three gates consistent, so the command does not become clickable-but-throwing: commands/catalog.ts (drop runAvailability: 'idle' for /rename only), controller/chat-controller.ts (drop assertNoActiveTurn('renaming a session'); archive/restore keeps its own), controller/product/feature-flow.ts (onRename no longer takes the live-navigation rejection; /sessions, /new and archive keep theirs).

    One behavior change worth your review: updateState() cleared error unconditionally, so a mid-turn rename dropped the failure banner the running turn was showing — and /retry reads that same error to offer a resend. It now clears only when no in-process run is active.

    Verified locally: tui-chat-controller, commands/catalog, command-flow, feature-flow, tui-keybindings, session-manager → 195 passed; tsc -p tsconfig.standalone.json clean. Not verified: Linux/macOS and a manual TUI session against a live model.

    Also worth knowing before this is picked up: while a turn is stopping (cancelling/retiringTurnId/runtimeStopping), isAvailableWhileStopping admits only help/quit/stop, so /rename is refused there. I read "while a turn is running" as the normal-running case and left that window alone — say the word if you want it opened too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesttuiInteractive terminal UI (TUI)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions