[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.