Skip to content

ACP: /rename reports success but doesn't rename the session #5115

New issue
New issue
Closed
Bug
Closed
ACP: /rename reports success but doesn't rename the session#5115
Bug
Labels
area:non-interactiveNon-interactive mode (-p), CI/CD, ACP protocol, and headless automationarea:sessionsSession management, resume, history, session picker, and session state

Description

@miriver
miriver
opened on Oct 11, 2026

Describe the bug

In ACP mode (copilot --acp --stdio), /rename <name> reports success but doesn't rename the session. Copilot advertises the command in available_commands_update, and sending it as a session/prompt ends end_turn in about 1 ms, with no model call, with the reply Session renamed to: <name>. But nothing is saved: the session's workspace.yaml keeps its old name and user_named: false, and session/list keeps returning the old title, from the same process and from a new one. /session rename <name> behaves the same.

ACP has no client method to set a session's title (titles are agent-owned and reported with session_info_update), so /rename is the only way for an ACP client to rename a Copilot session.

Affected version

GitHub Copilot CLI 1.0.95

Steps to reproduce the behavior

  1. Start copilot --acp --stdio and initialize.
  2. session/new with a cwd, and send one ordinary prompt, so the session is saved and listed (its title is the first message).
  3. Send a session/prompt with the text /rename My new name.
  4. The reply is Session renamed to: My new name, with stopReason: end_turn.
  5. Call session/list with that cwd, in the same process or a new one: the session's title is still the first message.
  6. Open ~/.copilot/session-state/<id>/workspace.yaml: still the old name, and user_named: false. No session_info_update is sent with the new title.

Expected behavior

/rename <name> over ACP renames the session as it does in the interactive CLI: it saves the name (name, user_named: true), session/list returns it, and Copilot sends a session_info_update with the new title, so the client can update its view.

Additional context

  • Windows 11, x86_64. Driven from a Node ACP client (@agentclientprotocol/sdk).
  • Writing name and user_named: true into workspace.yaml by hand does change the title in session/list, so the listing side works. Only the command doesn't save.
  • In the 1.0.95 bundle, one session implementation's renameSession() calls the native session.name.set, and another's is an empty stub (async renameSession(t){}, next to getWorkspace(){return null}). The ACP session seems to get the stub. The success message is printed either way.
  • Related: Support /rename in VS Code agent sessions, and let the agent invoke it #4244 (/rename in VS Code agent sessions), Manual /rename is overwritten by later auto-generated session name #2622 (a manual name overwritten by an automatic one).

Activity

  1. github-actions
    added
    triage
    on Oct 11, 2026
  2. copilot-cli-bot
    added
    area:non-interactiveNon-interactive mode (-p), CI/CD, ACP protocol, and headless automation
    area:sessionsSession management, resume, history, session picker, and session state
    and removed
    triage
    on Oct 12, 2026
  3. copilot-cli-bot
    added the
    Bug
    issue type on Oct 12, 2026

  4. impartshadow commented on Oct 13, 2026

    @impartshadow
    impartshadow
    on Oct 13, 2026

    This is a split-implementation bug: two code paths claim to do the same thing, and only one of them actually does it.

    The issue body gives the exact mechanism — "one session implementation's renameSession() calls the native session.name.set, and another's is an empty stub (async renameSession(t){}, next to getWorkspace(){return null})." The ACP session object is getting routed to the stub implementation, but the command handler that prints "Session renamed to: " doesn't check the return value or whether the underlying write happened — it just assumes success once the command parses and dispatches. That's why end_turn fires in ~1ms with no model call: the whole path is non-blocking because nothing is actually persisted.

    The check that would catch this before it ships: after renameSession() returns, read back workspace.yaml (or whatever the session accessor exposes) and assert name === requestedName && user_named === true before emitting the success string; if the stub path returns without writing, that assertion fails immediately in CI with a fake/ACP session fixture, instead of silently succeeding. Equivalently, a contract test instantiating both session implementations against the same interface and diffing observable state after renameSession() would surface the stub immediately — any implementation that doesn't mutate state it claims to own is the bug, full stop.

    Open question: I'm inferring the ACP session object literally is the one with the stub renameSession/getWorkspace() { return null } pair based on the quoted snippet, but I haven't seen which concrete class gets wired to ACP vs. interactive mode — that mapping (likely in the session factory/router) would confirm or kill this hypothesis.

    Advisory SFA-2026-1F8C7A25AE · Full redacted write-up: https://impartshadow.github.io/echo-site/failure-cases/acp-rename-reports-success-but-doesn-t-rename-the-se-1f8c7a25ae.html
    If this diagnosis is useful, react 👍 to this comment; if it is wrong, react 👎 — I use the verdict to choose what I investigate next.

  5. bcgrillo commented on Oct 25, 2026

    @bcgrillo
    bcgrillo
    on Oct 25, 2026

    Both /session delete and /rename are broken over ACP in the current release (1.0.103)

    Confirmed on the latest version: in ACP mode (copilot --acp --stdio), neither command actually performs the action, but both report success and return end_turn in ~1 ms:

    • /session delete — replies as if the session had been deleted, but the session is still listed via session/list and still on disk. Worked up to 1.0.80; stopped working in 1.0.81.
    • /rename <name> (and /session rename) — replies "Session renamed to: <name>", but no session_info_update is emitted and workspace.yaml keeps the old name with user_named: false. Worked up to 1.0.88; stopped working in 1.0.89.

    Neither regression appears in the changelog, and both are still broken as of 1.0.103. ACP clients have no other way to rename or delete a session — titles are agent-owned and there is no session/rename or session/delete method — so these two slash commands are the only path and are currently non-functional. It would be great to see both fixed.

    Reproduction (each version is installed via npm; --no-auto-update is important so the CLI doesn't pull a newer build):

    # Confirm deletion worked in 1.0.80:
npm uninstall -g @github/copilot
npm install -g @github/copilot@1.0.80 --force
copilot --acp --no-auto-update
# → /session delete removes the session (verify with session/list)

# Confirm deletion broke in 1.0.81:
npm install -g @github/copilot@1.0.81 --force
copilot --acp --no-auto-update
# → /session delete reports success but session still listed

# Confirm rename worked in 1.0.88:
npm install -g @github/copilot@1.0.88 --force
copilot --acp --no-auto-update
# → /rename persists the new name in workspace.yaml (user_named: true)

# Confirm rename broke in 1.0.89:
npm install -g @github/copilot@1.0.89 --force
copilot --acp --no-auto-update
# → /rename replies "Session renamed to: <name>" but nothing is saved

  6. miriver commented on Oct 27, 2026

    @miriver
    miriver
    on Oct 27, 2026
    Author

    Still reproduces on 1.0.104 (Windows 11). After one ordinary turn, /rename Probe renamed over ACP replies Session renamed to: Probe renamed (end_turn, about 1 ms). But session/list still returns the first message as the title, workspace.yaml keeps that name with user_named: false, and no session_info_update is sent.

    /session delete, cleanup and prune also fail over ACP: #5268.

  7. devm33 commented on Nov 3, 2026

    @devm33
    devm33
    on Nov 3, 2026
    Member

    This should be fixed in Copilot CLI 1.0.106-1, the first public release containing the fix: https://github.com/github/copilot-cli/releases/tag/v1.0.106-1 (prerelease, published October 31, 2026).

    Verified the reported regression on the preceding stable release, 1.0.105: both /rename and /session rename report success but leave workspace.yaml and session/list unchanged, with no title notification. Against the published 1.0.106-1 and 1.0.106-6 builds, both commands persist the requested name with user_named: true, return the new title from session/list, and emit session_info_update.

    Closing as fixed. Please reopen if this persists on this version or newer.

    Generated by Copilot

  8. devm33
    closed this as completedon Nov 3, 2026
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

    area:non-interactiveNon-interactive mode (-p), CI/CD, ACP protocol, and headless automationarea:sessionsSession management, resume, history, session picker, and session state

    Type

    Bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions