[Bug]: Codex Priority inherited from config is hidden as Standard

[HeeroML]

Before submitting

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

Area

apps/server

Steps to reproduce

1. Set Codex's effective configuration to Fast/Priority, so config/read reports service_tier = "priority".

2. In T3 Code, use an All projects, project, or existing thread model selection with no explicit serviceTier, for example:

   {
     "instanceId": "codex",
     "model": "gpt-6-astra"
   }

3. Open or resume that thread in T3 Code.

4. Observe that the composer shows Standard/no Fast lightning-bolt indicator.

5. Send a turn.

6. Inspect the T3 provider event and the Codex rollout's thread_settings_applied event.

This was reproduced from normal persisted state after the All projects selection omitted serviceTier; no database editing was required.

Expected behavior

If the effective Codex tier is Priority/Fast, T3 must visibly show Fast before a turn runs. If T3 displays Standard, it must explicitly dispatch serviceTier: "default" so the displayed and effective values cannot diverge.

An unset T3 selection may inherit provider configuration, but T3 must display that inherited effective value rather than a separate catalog default.

Actual behavior

T3 displays Standard/no Fast indicator while omitting serviceTier from session and turn dispatch. Codex then inherits the top-level service_tier = "priority" and applies Fast mode.

The Codex service tier is global and independent of the selected model, so a Priority setting present while Luna was selected also affected Astra threads when T3 supplied no explicit tier.

Sanitized evidence from the affected installation:

• No T3 project default was explicitly configured as Fast/Priority.
• The machine-wide All projects selection specified Codex/Astra but omitted serviceTier; most projects inherited it.
• Five persisted Codex threads also had no serviceTier selection.
• The pre-workaround Codex configuration explicitly contained service_tier = "priority".
• One affected rollout recorded 40 thread_settings_applied events with service_tier = "priority".
• T3's provider log reported thread/settings/updated ... serviceTier=priority for the same effective session.
• T3 still showed no Fast state.
• After changing Fast to Standard in Codex CLI, the config became service_tier = "default"; a new T3 session and Codex rollout both recorded default.

The upstream path appears to be the gap between:

• fix(models): restore sticky new-thread selections #9164, which intentionally changed T3 to dispatch only explicit selections so unset options can inherit provider configuration; and
• still-open fix(codex): honor configured provider model defaults #8913, which reads Codex config/read values, including service_tier, back into T3's displayed provider defaults.

The installed build contains #9164 but not #8913. Closest issue #9804 was closed after restoring machine-wide controls, but it did not establish this effective-tier mismatch or measured accelerated usage. #6306 is adjacent but only covers T3's local cost estimate underpricing already-visible Fast turns.

Suggested regression coverage:

1. Codex config/read returns priority and T3 has no explicit tier: the composer visibly shows Fast before the first turn.
2. T3 explicitly selects Standard while Codex config is Priority: T3 dispatches default and Codex applies Standard.
3. Verify both the displayed descriptor and effective/dispatched tier at an integration seam.
4. If effective configuration cannot be read, show the tier as unknown rather than confidently presenting Standard.
5. Cover existing threads and machine/project defaults whose stored selection omits serviceTier.

Impact

Major degradation or frequent failure

This is a usage-safety issue. The UI can confidently indicate Standard while the provider uses an accelerated tier with increased usage. In this incident, affected T3 Codex sessions exhausted usage far faster than expected and the mismatch took approximately eight hours to diagnose.

Version or commit

T3 Code 0.0.40-nightly.20260907.1359 (357b8d5217cd)

Environment

Fedora Linux 44, T3 server/shared web UI, Node 22.22.2, Bun 1.4.2, Codex CLI/app-server 0.153.4, Codex GPT-6 Astra

Logs or stack traces

T3 All projects model selection:
{"instanceId":"codex","model":"gpt-6-astra"}
# serviceTier is absent

Codex configuration before workaround:
service_tier = "priority"

Effective T3/Codex session:
thread/settings/updated ... serviceTier=priority
thread_settings_applied ... service_tier=priority

After selecting Standard in Codex CLI:
service_tier = "default"
thread/settings/updated ... serviceTier=default
thread_settings_applied ... service_tier=default

Thread IDs, project paths, prompts, credentials, and unrelated configuration have been omitted.

Workaround

Set Codex CLI to Standard/Default, or explicitly configure serviceTier: "default" in every applicable T3 All projects, project, and thread selection. Existing omitted selections remain vulnerable to future Codex configuration changes until T3 displays the inherited effective tier.

[HeeroML]

Quick follow-up after checking #8913 against the exact reproduction: I do not think it closes this issue yet.

The PR applies the configured service_tier only to the model it marks as the Codex default. In my actual case, Codex had Luna as the configured model and service_tier = "priority", while T3 had Astra selected with no explicit serviceTier.

That means Astra can still keep the catalog Standard value in the UI, T3 still omits the tier on dispatch, and Codex still inherits global Priority. So this is basically the exact mismatch reported here.

The added test uses the same model as both configured and selected, so it does not cover Luna -> Astra. Also, if config/read fails, the PR falls back to {}, which still lets T3 confidently show Standard instead of unknown.

So Closes #10576 looks premature unless the cross-model case and displayed-vs-dispatched behavior are covered.