Title generation always runs on a hard-coded gpt-5.6-luna in an ephemeral thread, whatever provider the session uses #663

What happens

After a new session's first turn, TitleGenerator starts an ephemeral thread (thread/start { ephemeral: true }) and runs one turn with model: "gpt-5.6-luna", hard-coded, with no provider check and no way to turn it off (2.1.1, and unchanged on main).

Behind an LLM gateway that fronts several providers and routes each call by its model name, that call does not fail; it runs on whichever provider serves gpt-5.6-luna, which is not the provider the session was started on. The ephemeral thread carries no link to the session (its own fresh id, no parent), so a gateway that meters per session cannot attribute the call either. Each title turn carries Codex's full base instructions and tool schemas: in our records the session's first call had 25,625 input tokens and the title call 25,084, for a 3–7 word title.

With a provider that does not serve the model at all, the call fails and the first message is still sent to that provider, as #595 describes.

What would help

Any one of these:

• A switch to turn title generation off for the adapter process (what feat: allow disabling session title generation #485 added as ACP_DISABLE_TITLE_GENERATION, closed by its author before review).
• Skipping generation unless the session's provider is OpenAI's own (fix: skip AI title generation for sessions on other model providers #595).
• Letting the client name the session at creation (feat: name Codex threads from session/new _meta.sessionTitle #338), so a client that already titles sessions gets no generated one.

Codex's own TUI already does the second: it uses gpt-5.6-luna only on the openai provider when the catalog lists it, and the session's current model otherwise.

Until then we load the adapter through a Node module hook that keeps the generator from starting; happy to turn any of the above into a PR if that helps.