fix(server): a disabled bootstrap provider no longer stops startup

[ScottN-PV]

Problem

t3 (and t3 start) creates the project's first thread at startup using the project default model, or Codex when none is set. #17879 added the per-project enablement check to thread launch, so that launch now fails with ThreadManagementProviderInstanceDisabledError when the instance is disabled, and startup exits before command readiness. The reporter disabled Codex in the stable build, then ran the nightly t3.exe ZIP on Windows 11 and the window closed on the stack trace.

Change

Startup catches the launch's two typed failures and continues with the project and no bootstrap thread target. A disabled instance logs at info with the project and instance ids. A ThreadLaunchError logs at warning with the project id and operation. The model selection is unchanged: skipping this optional thread lets the app open without picking a replacement provider for the user. Project bootstrap, shell reads, defects and interruptions still fail startup as before.

Scope and approval

Closes #20028. The triage comment confirmed the bug and accepted either choosing an enabled provider or skipping the thread, plus not crashing startup. The nightly ZIP t3.exe runs the CLI/web server, where cwd auto-bootstrap defaults on. Desktop mode defaults it off and t3 serve forces it off.

Verification

cd apps/server && vp test run src/serverRuntimeStartup.test.ts src/serverRuntimeStartup.autoPull.test.ts:

• 12 tests pass in apps/server/src/serverRuntimeStartup.autoPull.test.ts, apps/server/src/serverRuntimeStartup.test.ts.
• With apps/server/src/serverRuntimeStartup.ts reverted to ede3f2d6ba, 3 tests fail with assertion errors: "keeps bootstrap launch failures separate from project failures: disabled-codex", "keeps bootstrap launch failures separate from project failures: disabled-default", "keeps bootstrap launch failures separate from project failures: launch-failure".
• vp fmt --check and vp lint report no errors and no new warnings on the 2 changed TS files.
• Typecheck passes for t3.

The new table test drives ServerRuntimeStartup.layerWithOptions through command readiness and the welcome event: disabled Codex with no default, a disabled explicit project default, a ThreadLaunchError, and an unrelated project-bootstrap defect that still fails readiness.

Real run on Linux, from source: two isolated node apps/server/src/bin.ts start --no-browser --auto-bootstrap-project-from-cwd processes, each with its own base dir, port and project folder, and a settings.json that disables the codex instance. With apps/server/src/serverRuntimeStartup.ts at ede3f2d6ba, the server logged the ThreadManagementProviderInstanceDisabledError startup failure and exited 1 before readiness. With the fix (04085eb871) it logged the skip, published welcome with the project id and no thread id, accepted commands, and answered GET /.well-known/t3/environment with 200. Both state databases held one project and zero threads.

Not run: Windows, the Electron desktop app, and the stable-to-nightly migration.

Model: GPT-6.1-Sol, Claude Opus 5.5, Claude Fable 5.1 (review), GPT-6-Astra (review). Harness: Codex, Claude Code.

[macroscopeapp]

Approvability

Verdict: Approved at 04085eb

Macroscope's review found this PR approvable — This is a narrowly scoped server startup bug fix: optional bootstrap-thread failures are logged and skipped while project bootstrap and other startup failures remain fatal. Regression tests cover disabled providers, launch errors, and preservation of project failure behavior.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: e346436e-5c4f-4a05-996d-4d2f015e677f

📥 Commits

Reviewing files that changed from the base of the PR and between 559c4b1 and 04085eb.

📒 Files selected for processing: 2

• apps/server/src/serverRuntimeStartup.test.ts
• apps/server/src/serverRuntimeStartup.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

📝 Walkthrough

Server startup now continues when bootstrap thread launch fails because a provider instance is disabled or a thread launch error occurs. Tests cover these cases and project bootstrap failure.

Changes: Bootstrap startup

Layer / File(s)	Summary
Bootstrap launch handling and tests apps/server/src/serverRuntimeStartup.ts, apps/server/src/serverRuntimeStartup.test.ts	Startup logs disabled provider errors at info level and other thread launch errors at warning level. Both cases leave the thread ID unset while retaining the bootstrap project ID. Parameterized tests check command readiness and welcome events across the launch and project bootstrap scenarios.

Priority: ⬆️ High

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: t3dotgg

Merge Risk: ⚪ Minimal · up to 04085

Startup can continue without a bootstrap thread, and the welcome event supports that state. No merge-blocking issue was identified.

Security architecture risk: 🔵 Low · up to 04085

Startup can continue without an initial thread while preserving provider enablement checks and the existing welcome format. No introduced security bypass was identified. Residual uncertainty concerns recovery after partially completed launches.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed behavior concerns readiness after bootstrap of the configured working-directory project. The inspected delta adds no caller-supplied launch authority or replacement provider; it permits the existing server to finish startup after the optional launch fails.

Trust Boundaries and Controls

• observed — Provider enablement is checked before thread-ID allocation, managed-folder selection, or thread creation. Catching the rejection does not retry with another provider. The existing dispatch wrapper also retains enablement checks for message dispatch and delegated-task requests.

Resilience and Maintainability Implications

• observed — Launch receipt replay recovers an accepted thread identity, while orchestration serializes dispatch per thread and rejects receipt replay against a conflicting thread. These existing controls remain in the continued-startup path.
• inferred — A Scratch-root launch can claim a directory before thread creation fails. This ordering and absence of local compensation predate the PR; no increased repetition or authority was established. Global cleanup remains unverified, so the catch must not be interpreted as proof that every failed launch leaves no state.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the primary change: disabled bootstrap providers no longer prevent server startup.
Description check		The description covers the problem, change, scope and approval, focused verification, observed results, and untested environments. It includes the linked issue and triage approval context.
Linked Issues check		The change addresses #20028. resolveAutoBootstrapWelcomeTargets catches ThreadManagementProviderInstanceDisabledError and ThreadLaunchError, logs each typed failure, and returns no bootstrap thr…
Out of Scope Changes check		The diff is limited to optional bootstrap-thread error handling in apps/server/src/serverRuntimeStartup.ts and focused startup tests in apps/server/src/serverRuntimeStartup.test.ts. The logging an…

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}