fix(web): default provider selection for users without Codex

[mfazekas]

What Changed

• Command palette project creation no longer hard-codes codex as the new project's defaultModelSelection. It resolves the first usable provider instance (ready → non-error → enabled, then the codex literal), stamps that instance's own default model, and adds the missing providers entry to the callback dependencies so the handler does not act on the at-mount provider snapshot.
• The composer's instance resolution falls through to an enabled instance when the persisted instance id is known-but-disabled — but only when an enabled instance satisfies the thread's driver/continuation lock; otherwise the id is kept so the accurate "provider disabled" server error surfaces. Unknown ids (e.g. a custom instance not yet hydrated) are still returned as before. The composer's driver kind now follows the resolved instance, so options and send context stay consistent with the instance that actually runs.
• resolveSelectableProviderInstance tiers its fallback by probe status and getDefaultProviderInstanceModel provides an instance-scoped default model. Unit tests cover the tiering, requested-instance retention, and the model helper.

Why

Fixes #4116. New users without Codex get their first palette-created project defaulted to codex, so the first thread fails (Failed to spawn Codex App Server process on fresh settings, or Provider instance 'codex' is disabled in T3 Code settings. when codex is disabled) and the thread stays permanently pinned to codex. The composer change also lets existing broken threads recover: on the next send they fall through to a working provider.

UI Changes

Before (thread pinned to codex, turn fails, composer shows the OpenAI icon with a claude model):

After (same flow defaults to the ready Claude instance and the send succeeds):

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Fix default provider selection for users without Codex access

• Removes hardcoded codex as the default provider/model across project creation, the chat composer, and the command palette; new projects now start with null for defaultModelSelection.
• Adds NO_PROVIDER_MODEL_SELECTION as a sentinel value in providerInstances.ts and new helpers (resolveDefaultProviderModelSelection, resolveSelectableProviderInstanceEntry, getDefaultProviderInstanceModel) that prefer ready/non-error instances and return null when no viable provider exists.
• The chat composer disables send actions and replaces the model picker with a disabled "No provider available" notice when no provider instance is selectable.
• Behavioral Change: resolveSelectableProviderInstance may now return undefined instead of always falling back to the first enabled instance, and stored defaultModelSelection on new projects is null instead of a codex default.

📊 Macroscope summarized 44b14f4. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

---

Note

Medium Risk
Changes default model selection and composer send gating across project creation and chat, but behavior is covered by expanded unit tests and narrows failure modes for misconfigured providers.

Overview
Stops assuming Codex as the default provider when none is configured or available. New projects from the command palette and the low-level project.create path now get defaultModelSelection from resolveDefaultProviderModelSelection (first ready instance, then non-error, with that instance’s default model) or null when nothing is sendable. Draft threads without a project default use a local NO_PROVIDER_MODEL_SELECTION placeholder instead of inventing Codex.

providerInstances gains instance-scoped getDefaultProviderInstanceModel, tiered resolveSelectableProviderInstanceEntry, and shared default-resolution logic; errored instances are not auto-picked for new users but can stay selected when explicitly requested.

The composer resolves the active instance via the new helpers (respecting locks), drives UI/send off whether a real provider exists (providerAvailable), and blocks send with “Enable a provider in Settings” / “No provider available” when none is available. ChatView send paths honor providerAvailable and drop the Codex fallback in provider resolution.

^{Reviewed by Cursor Bugbot for commit 44b14f4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 09cb6ed8-bcdf-4944-9c58-6615137a5fd2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

1 blocking correctness issue found. This PR introduces significant behavioral changes to provider selection logic with new fallback mechanisms and UI states. Two unresolved medium-severity review comments identify potential bugs in the new resolution logic (partial hydration issues and settings overlay not being applied).

^{You can customize Macroscope's approvability policy. Learn more.}

[mfazekas]

Pushed a follow-up commit addressing the review findings:

• Bugbot high (composer driver lags instance fallthrough): the composer now derives its driver kind from the resolved instance entry, so options and send context follow the instance that actually runs.
• Bugbot medium (default model ignores resolved instance): project creation now uses an instance-scoped model lookup (getDefaultProviderInstanceModel) instead of the driver default.
• Additionally, resolveSelectableProviderInstance falls back ready → non-error → enabled (an errored codex probe could previously still win by list order during the startup window), and the composer only abandons a known-disabled persisted instance when an enabled instance satisfies the thread's driver/continuation lock — otherwise it keeps the id so the accurate "provider disabled" error surfaces instead of a confusing driver-switch rejection.

Added unit tests for the fallback tiering, requested-instance retention, and the model helper.

Dismissing prior approval to re-evaluate 44b14f4

[macroscopeapp]

🟡 Medium src/providerInstances.ts:299

resolveSelectableProviderInstanceEntry silently replaces a persisted instanceId whose snapshot hasn't arrived yet with the first ready/non-error instance, because it treats a not-yet-hydrated custom instance the same as a deleted one. During partial provider hydration, this causes callers to dispatch turns through the wrong provider instead of retaining the unknown ID until its snapshot arrives. Consider distinguishing absent-but-known IDs from stale ones, or preserving the original instanceId when no matching entry is found instead of eagerly substituting a fallback.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/providerInstances.ts around line 299:

`resolveSelectableProviderInstanceEntry` silently replaces a persisted `instanceId` whose snapshot hasn't arrived yet with the first ready/non-error instance, because it treats a not-yet-hydrated custom instance the same as a deleted one. During partial provider hydration, this causes callers to dispatch turns through the wrong provider instead of retaining the unknown ID until its snapshot arrives. Consider distinguishing absent-but-known IDs from stale ones, or preserving the original `instanceId` when no matching entry is found instead of eagerly substituting a fallback.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 44b14f4. Configure here.}

[cursor]

Defaults ignore settings overlay

Medium Severity

New project defaults call resolveDefaultProviderModelSelection on raw serverConfig.providers (or the primary providers atom) without applying applyProviderInstanceSettings. A provider disabled in settings can still look enabled in the probe snapshot, so palette-created projects can be persisted back onto that instance—the same failure mode this PR aims to fix.

 

^{Reviewed by Cursor Bugbot for commit 44b14f4. Configure here.}