Agent CLI: t3 thread launch is refused on Lazurio Environments, because an MCP launch reads only the project record's legacy default model #94

What happens

t3 thread launch (#91) is refused on the Lazurio Environments where I tried it on 2026-10-20: the reference Organization's admin-01 and one personal Environment, both on 0.1.0-lazurio.5. It is refused even where the web starts new threads in the same project without asking for a model:

{"error":{"code":"invalid_request","message":"Pass modelSelection: the project has no default model. orchestrator_capabilities lists providers and models."}}

The other agent commands work against the live server: thread list, request list, events, and a session with --runtime-mode-ceiling full-access. The launch is the one that fails, and it is the key capability for a person's own agent. Decision 0189 gives the command no model flag, so an agent outside a thread has no way around it.

Why

t3_thread_launch takes input.modelSelection ?? caller.modelSelection ?? project.defaultModelSelection (apps/server/src/mcp/toolkits/project/handlers.ts, around line 126). The last of these is the project record's legacy field.

The web resolves a project's default model differently, through resolveProjectOverrides (packages/shared/src/projectSettings.ts, around line 146), in this order:

1. settings.projectSettingsOverrides[project].defaultModelSelection;
2. the record's legacy field, only while projectSettingsFolded is false;
3. the Environment default settings.defaultModelSelection.

Lazurio writes its model recommendation into the settings override (t3 lazurio model, overlay row 15). Once settings are folded, the record field stays null on every Lazurio Environment. So the launch finds no model even where the web finds one, either the Lazurio recommendation or the person's own default.

#91's contract tests use fake orchestration services, so they never reached this check.

Workaround used on one personal Environment

These two steps made the launch work: a full-access thread on gpt-6.1-sol answered and was archived.

1. lazurio chat defaults reported outdated there: the managed recommendation had never been applied on that Environment. lazurio chat defaults --apply wrote it.
2. The Folder project's override model was copied into the project record through t3_project_update. That needs a full-access MCP client, now possible with t3 auth session issue --runtime-mode-ceiling full-access. The web ignores that field on folded settings, so nothing changes there.

The same workaround would be needed on every Environment, so it is not a fix.

Proposed fix

Preferred: resolve the launch's model through resolveProjectOverrides, the same way the web does, in t3_thread_launch and in the other paths that start a thread for a caller outside one.

• It fixes the CLI and every MCP client outside a thread, Buddy's MCP path included.
• It is a focused upstream bug: an MCP launch ignores the project's settings override and the Environment default.
• So it is a candidate for an upstream offer, with a small allowlisted overlay hunk until upstream has it.

Alternative (overlay only): t3 thread launch resolves the effective default itself, through the shared resolver over the T3 home's settings, and passes it as modelSelection.

Acceptance: where the web starts a new thread in the Lazurio project with model X, t3 thread launch starts one with model X, with no t3_project_update beforehand.