Cursor already auto-generates chat titles, so agents should also be able to update chat titles programmatically when the real task becomes clear.
Right now, the agent often understands the session purpose better than the user in the moment, especially when a task number or exact scope only becomes clear after a bit of work. In our workflow, chat titles are not cosmetic, they’re part of task organization and session history.
A good example is task-based naming like:
T136 - Fix singularization scoring
or for task creation sessions:
Create: T135-T136-T137 - scraper follow-ups
Today, the only workaround is manual renaming by the user, which breaks flow and makes it harder to keep sessions organized consistently.
What would help:
rename current chat programmatically
rename a chat by chat ID
return success plus the final title
This could be exposed however fits Cursor best: API, MCP tool, command surface, or internal agent capability. The important part is that it is official and reliable.
If Cursor can generate chat names automatically, agents should also be able to keep those names accurate as the actual task becomes clear.
I tried building a VSCOde extensionf or this, but Cursor doesn’t expose anything (that I could probe) to expose this capabaility.
Cursor team - Coudl you: Request: Programmatic rename for Agent / Composer chats
Problem
Today, users can manually rename an agent/composer chat (e.g. sidebar → Rename), but there is no supported, documented way for:
AI agents (or automation) to set the visible chat title when scope or outcome becomes clear, or
Integrations (scripts, MCP, other extensions) to keep the Agents list consistent with task IDs, PR numbers, [done] prefixes, etc.
Exploratory work in a normal VS Code-style extension shows internal commands such as composer.updateTitle and composer.getOrderedSelectedComposerIds, but composer.updateTitle does not reliably change the Agents sidebar title under real use (no documented contract; getComposerHandleById often returns null from extensions). This is not a viable public integration.
Goal
Expose a small, explicit, stable surface so trusted callers can set the human-visible title of a chat/agent session without simulating UI.
Primary use cases
Agent self-labeling — After the first real turn, set title to a short task summary (or user rule like PRR repo#123: …).
Workflow tags — Prefix/suffix when work completes ([done], [blocked], task id).
Multi-chat hygiene — Parallel agents; titles must stay searchable and scannable.
Tooling — MCP server or local extension invoked by the agent renames the current session.
Proposed surface (pick one or ship both)
Option A — Command palette / executeCommand (extension-callable)
Add a documented command, e.g.:
cursor.agent.renameCurrentChat
Args:{ title: string } or a single string (your choice; document one).
Semantics: Rename the currently focused agent/composer chat in this window (same notion of “current” as the UI’s Rename).
Returns:void or { ok: true } / structured error.
Errors: e.g. no active chat, title empty, title too long, policy denied — throw or return with stable error codes.
Optional advanced form (if you want multi-tab control):
cursor.agent.renameChat
Args:{ sessionId: string, title: string }
sessionId documented: same id users/extensions can obtain from a documented “list sessions” or “get current session” API.
Option B — MCP tool (agent-native)
Register a first-party MCP tool, e.g. cursor_rename_current_chat, with:
Input:{ "title": "string" }
Behavior: Same as Option A for “current chat in this window.”
Visibility: Only when the agent session is allowed to use it (align with existing tool policies).
This is what makes “the agent renames this tab” natural without a custom extension.
Semantics you should specify in docs
Which window: “Current Cursor window only” (matches how workbench state works).
Which chat: “The active/focused Agents/Composer session” — match exactly what the context menu Rename targets.
Limits: Max length, disallowed characters, truncation behavior.
Persistence: Same as manual rename (storage, sync if applicable).
Versioning: Command id + argument shape stable across minor releases; breaking changes in release notes.