[Feature]: Let the agent update its thread title once the work is actually decided

[dbtlr]

The problem

Thread titles are generated from the first user message, but for me the first message is almost never what the session ends up being about. That's because my workflow includes using the agent to work through pre-defined task lists for large bodies of work. You can imagine that I've built a flow that uses large planning sessions with things like the grilling skill, to develop large specs that are then broken into smaller pieces. These tasks exist as a sort of agent hand off for these that are sometimes worked individually or as part of larger workflow automations.

Because of this, a large percentage of my sessions start with me querying about the task board: "what are the top priorities right now?" or just "what's next for phase 2?". The agent and I look at open work, agree on a plan, and then start the actual task. The title generator has already run by that point, so my thread list fills up with titles like:

• "Discuss next priorities"
• "Review open tasks"
• "What's next"

For me, many of these threads that are actually "Fix OAuth keychain fork on macOS" or "Implement v0 plugin API". By the time the thread has a real subject, the title is frozen on the warm-up conversation.

What I'm asking for

The recently added Regenerate title button is exactly the right operation; thank you for adding it. I use it, and it works. The gap is that it's manual: I have to notice the stale title and click, once per thread, multiple times per day. The result is that I often don't and my beautiful left side nav is full of generic titles, so going back to old threads feels impossible.

The ask: expose that same operation to the agent session, so a workflow (in my case, a "start task" skill that runs after we've agreed on the work) can trigger it at the moment the thread's subject actually crystallizes. Conceptually it's "the Regenerate title button, callable from inside the session at the right point in the workflow"; not a new capability, a new trigger for an existing one.

Why I don't think this is scope creep

• The mutation path already exists and already ships. Title regeneration is an existing orchestration command with an existing worker; this proposal adds a caller, not a subsystem. No schema changes, no UI changes, no new dependencies.
• There's already precedent for provider-initiated renames. The Codex and OpenCode adapters both propagate their native session-rename events into the thread title today (thread.metadata.updated → title update). Claude Code has no native rename event, so Claude sessions are the odd one out. This is closer to parity than to a feature. Part of the mcp's instructions could (in theory) help teach claude to call this when it rename's its own session.
• Auth is already scoped correctly. Each session's MCP bearer is bound to its own thread, so a tool registered on the existing t3-code MCP server can only ever touch the thread it belongs to. No new auth surface.
• Small diff. One or two MCP tool registrations dispatching an existing command, plus tests. Nothing near the size you've said you don't want to review.

Two possible shapes

• thread_regenerate_title - The agent supplies nothing; the tool just triggers the existing server-side regeneration, which now has the full conversation to work from. Titles stay entirely under T3's generation logic, so an agent can't write junk into the thread list. The most conservative version, and shipping only this would solve my problem completely.
• thread_set_title(title) - The agent supplies the title directly. This is honestly my preference: the in-session agent knows what task it just picked up from context (ticket ID, agreed scope), which an outside generation pass reading the transcript has to reconstruct. But it does let agent-authored text into the UI, and if that's a line you don't want to cross, option 1 alone is a 100% acceptable answer.

Try it in one prompt

If you want to kick the tires before deciding anything, here are two self-contained prompts you could hand to your own agent in the repo. They encode the shape above; treat them as a starting point, not a spec.

Prompt A - thread_regenerate_title only (smallest version):

In this repo, add one MCP tool to the "t3-code" MCP server that spawned agent
sessions already receive, letting a session trigger regeneration of its own
thread's title.

Context to work from:
- The MCP server is built in apps/server/src/mcp/McpHttpServer.ts; tools are
  registered from toolkits (see apps/server/src/mcp/toolkits/preview/tools.ts
  for the existing pattern). The invocation context / McpSessionRegistry
  already binds each bearer token to exactly one thread.
- Title regeneration already exists: a `thread.meta.update` orchestration
  command with `regenerateTitle: true` (see packages/contracts/src/orchestration.ts,
  the decider, and threadTitleRegenerationWorker in
  apps/server/src/provider/ProviderCommandReactor.ts). The UI's "Regenerate
  title" action uses this path.

Task:
- Add a `thread_regenerate_title` MCP tool with no input parameters. It
  resolves the calling session's thread from the invocation context and
  dispatches the same `thread.meta.update { regenerateTitle: true }` command
  the UI uses. Return a short confirmation (thread id + whether regeneration
  was queued or already pending).
- Put it in a new, tiny toolkit (ex: "thread") rather than widening the
  preview toolkit's dependencies (the preview toolkit deliberately only
  depends on the preview broker).
- The tool must only ever affect the caller's own thread. No UI changes.
- Add tests mirroring the existing MCP toolkit tests: happy path dispatches
  the command for the bound thread; a second call while regeneration is
  pending is a no-op/acknowledged-pending; the tool never accepts a thread id
  from the caller.

Keep the diff small and focused; follow existing code style and Effect
patterns already used in the MCP layer.

Prompt B - both tools:

Everything in the previous prompt, plus a second tool in the same new toolkit:

- `thread_set_title` with a single required input `title: string`. It
  resolves the calling session's thread from the invocation context and
  dispatches `thread.meta.update` with the explicit title (same command the
  server already uses when it writes generated titles).
- Validate the input since agent-authored text reaches the UI: trim
  whitespace, reject empty strings, strip control characters and newlines,
  and cap length to match whatever limit the title generator/UI already
  assumes (reuse an existing constant if one exists rather than inventing
  one).
- Setting a title should supersede any pending regeneration for that thread
  the same way the existing decider handles a direct meta update.
- Tests: happy path writes the title through the existing projection
  (projection_threads.title); validation rejects empty/oversized/multiline
  input; the tool only affects the caller's own thread.

Same constraints: small diff, no UI changes, existing patterns.

Happy to build it, fine if not

If this seems reasonable I'd like to contribute it as a small, focused PR. I've read CONTRIBUTING.md and the PR template and while no screenshots would be needed since there's no UI change, I'd instead include a short clip of the title updating mid-session. If it's not a direction you want, that's a fine answer too. thankfully the manual button has already improved things, but this hook would definitely help me fully define a workflow that doesn't start with the prompt, but instead develops one.

[alcxyz]

We have been testing opt-in recurring title updates in a fork, built on #10720. During normal turns, the agent can update its own generated title when the objective changes. Manual titles stay protected; cooldown and activity requirements limit churn; snoozed, archived and settled threads are excluded. There is no separate title-generation call.

I saw that #2829, through #8690, already exposes rename and regenerate. Would a focused follow-up adding automatic-update policy to that existing tool be welcome? The fork also has rename history and undo, which can stay in a separate contribution.

Implemented with GPT-6 Astra in Codex; reviewed with Claude Fable 5.1.

[dbtlr]

Hey! Thanks for the follow up. I'm not sure that I necessarily was looking for automatic updates. I'd certainly test it out, but my primary need was to add it into my start task skill, so that it happens at a specific point by the agent who already has the correct context. I'd be open to testing g the other, though.

[alcxyz]

Thanks for clarifying, @dbtlr, and for offering to test it! Renaming at a specific point in your start-task skill makes sense. I’ve opened #11744 for the optional automatic-update behavior so the two use cases stay separate.

I’d welcome your feedback. The source branch is linked there, though there isn’t a packaged test release yet. Feedback on when titles should change and when they should stay put would be especially useful.

[PixPMusic]

Following the closure of #13305, I’d like to agree on a smaller scope: let the agent explicitly rename only its current thread.

The use case is the one described here: a thread starts with planning or triage, then a user or skill asks the agent to name it after the work that was actually chosen. The agent already has that context; the user currently has to perform the rename separately.

The proposed scope for a contribution against main is:

• One write tool, set_thread_name({ name }), on the existing T3 MCP endpoint. The credential determines the current thread; the caller cannot supply another thread ID.
• Reuse the existing title validation and thread.meta.update command. Treat the result as an explicit title choice, including invalidating pending automatic title generation. Existing clients receive the normal title update, and the user can rename it again.
• Grant only the capability needed for that rename. Exposing this mutation to agent sessions is part of the approval request.
• Focused tests for credential scoping, invalid names, missing/deleted threads, persisted renames, and protection from a late generated title.

This removes the metadata reader, model/service-tier/host/environment access, Daybreak changes and dependency, and provider-session tracking from #13305. It adds no recurring rename policy, regeneration tool, or new client UI.

I saw Julius’s direction on #11564 to continue here, and verified that #2829 already implements t3_thread_update with action: "rename" on its current head. Would you prefer that we wait for V2, or would you approve a small current-thread-only rename contribution to main ahead of it? I’ll wait for explicit direction and scope approval before implementing or opening a replacement PR.

[juliusmarminge]

Thanks for explaining the title-generation workflow and proposing both options. The orchestrator V2 work has now merged in #2829.

V2 exposes metadata updates to agents, including setting an explicit thread title and requesting title regeneration. A skill can now ask the agent to rename its thread once the actual task is agreed.

Closing this as delivered. If a specific part is still missing in a build containing V2, please open a focused follow-up with the provider/version and the behavior you are seeing.