[Bug]: t3 always passes a title at OpenCode session.create, which suppresses OpenCode's own title generation

[imluckii]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Use the OpenCode provider (opencode 1.18.32).
2. Create a thread in t3 and send a message.
3. Open the native OpenCode TUI and check the session's title.

Expected behavior

OpenCode generates its own session title after the first prompt (SessionPrompt.ensureTitle), so the session should end up with a readable generated title, like it does when the session is created from the native OpenCode UI.

Actual behavior

OpenCode never generates a title for t3-created sessions. ensureTitle bails out unless the session title still matches the default New session - <timestamp> pattern (packages/opencode/src/session/prompt.ts, if (!Session.isDefaultTitle(input.session.title)) return). But t3 always passes its thread title at session.create (input.title in OpenCodeAdapter), so the session is never default-titled and the title generator is skipped. Confirmed in opencode logs: sessions created by t3 log no agent=title run, while native untitled sessions do.

The session title therefore stays whatever t3 sent (the prompt-seed title), and the generated-title session.updated event t3's mirror listens for never fires. Renaming the thread in t3 doesn't help, since t3 also never updates the session title after creation.

Possible fix direction: don't send a title at session.create (or send it only after the user manually renames the thread), letting OpenCode's own title generation run and flow back through the existing mirror.

Impact

Minor bug or occasional failure

Version or commit

main @ f5ef0dd (tested on t3@0.0.43-nightly.20260922.2110)

Environment

Linux (headless VPS), OpenCode 1.18.32 driven through the t3 SDK. Also seen with the Cursor provider (session title in the Cursor CLI never reflects the thread title), untested with Claude Code / Antigravity.

[juliusmarminge]

Triage

Confirmed on main (f5ef0ddb): a provider session title is applied only while the thread title is still exactly New thread and the title has not been marked manual. A prompt-seeded title closes that window. This is the guard added for #5245 in #5941 and tightened in #10720, not an accidental drop.

The mirror is in ProviderRuntimeIngestion:

      if (event.type === "thread.metadata.updated" && event.payload.name) {
        if (thread.titleState?.source !== "manual" && canReplaceThreadTitle(thread.title)) {
          yield* orchestrationEngine.dispatch({
            type: "thread.title.generate.complete",
            commandId: yield* providerCommandId(event, "thread-meta-update"),
            threadId: thread.id,
            title: event.payload.name,
            expectedTitle: thread.title,
            expectedVersion: thread.titleState?.version ?? null,
            needsRefinement: false,
          });
        }
      }

canReplaceThreadTitle returns true only for New thread, or when the caller also passes a titleSeed and the current title is exactly that seed (apps/server/src/orchestration/threadTitles.ts). The provider mirror calls it with no seed. Tests lock this in: a provider rename is applied for New thread and ignored once the thread has any other title (ProviderRuntimeIngestion.test.ts).

The server's own first-turn generator does pass the seed (ProviderCommandReactor, around the thread.turn-start-requested handler), so it can replace a non-manual prompt seed. The provider path cannot. A seed that stays forever means that generator also did not apply: the title was marked manual, generation failed, or this was not the first user message.

Two corrections to the report:

1. Renaming the thread to New thread in the UI does not reopen the mirror. thread.meta.update sets titleState.source to manual (decider.ts), and the mirror refuses manual titles even when the text is New thread. The "rename back to New thread and the generated title lands" result only happens when the title text is New thread and the source is not manual (created that way, not renamed).

2. OpenCode 1.18.32 does not generate a title for a session that already has a non-default title. ensureTitle returns immediately unless the title matches New session - <ISO timestamp> or Child session - <ISO timestamp>. On session start, T3 passes thread.title into session.create (ProviderCommandReactor and OpenCodeAdapter). Official clients put the prompt seed on the thread before that call (mobile deriveThreadTitleFromPrompt, 72 characters; web truncate, 50 characters, then ...). If that seed is the title at create time, the native OpenCode session should keep the seed, not invent another title. A later generated title means session.create did not receive it.

Cursor is a separate gap. CursorAdapter never emits thread.metadata.updated, so there is no session title for this gate to accept or reject.

Treating every non-New thread title as replaceable would reopen #5245: thread.create still does not set titleState, so an explicit title and a prompt seed look the same. The narrower change is to let the provider mirror replace a non-manual title only when it equals the stored prompt seed, and to decide whether that should beat T3's own generator (both use compare-and-swap on expectedTitle, so whichever finishes last while the seed is still current wins). Getting a real OpenCode-generated title also means not sending placeholder seeds to session.create; sending them is what makes OpenCode skip ensureTitle.

If you can, paste the OpenCode session title from the create response and the title on the later session.updated, plus whether this thread's titleState.source is unset, manual, or generated. That separates "OpenCode generated a title and we dropped it" from "OpenCode kept the seed we sent it."

[imluckii]

Data you asked for, from the affected threads on my box (OpenCode 1.18.32, t3 nightly 20260922.2110 @ f5ef0dd):

OpenCode session title from session.create: it is the prompt seed. Examples from the opencode log created lines:

• ses_f34dbd8d6f... created with title="Add very slight \"progressive blur\" as you scroll. There is a small is..."
• ses_f35506a8a... created with title="There is a library called beautifulsoup4. Can you check it out and te..."
• ses_f35ed338a... created with title="hi"

The seed matches the first user prompt (mobile/web deriveThreadTitleFromPrompt-style truncation), so the create-time title is confirmed to be t3's seed, not OpenCode's.

Title on later session.updated: none. For every t3-driven session I checked, the title in opencode's own DB today is byte-identical to the create-time seed, and the opencode log shows zero agent=title runs for these sessions after create. Same install does generate titles for sessions created untitled through other clients (those log agent=title runs and get real generated titles), which matches your reading of ensureTitle. So this is the "OpenCode kept the seed we sent it" case, not "generated a title and we dropped it".

titleState.source on those threads: unset (null in projection_threads.title_state_json) for all the seed-titled ones. The only non-null sources on my server are generated on a few older threads that were titled by t3's own generator. No manual renames involved.

That also confirms your correction 1 - I never actually renamed back to New thread, that step in my repro was hypothetical and wrong; with source: manual set by a UI rename the mirror would refuse it regardless of text.

Happy to test a build that skips the title at session.create (or sends it only for manual titles) if useful.