›_ Codex Issues
Codex Issues / #35136

Desktop app strips documented service_tier config key from config.toml on launch

Open 💬 1 comment Opened Jul 24, 2026 by yannickspiess

Setting service_tier = "default" as a top-level key in config.toml (per the documented config reference, supported since PR #21697) persists correctly while the Codex Desktop app is quit. On launching the app, the key is silently removed from config.toml within seconds — the Desktop app appears to serialize its own internal settings model back to the file on load, and that model doesn't track service_tier, so it's dropped even though the CLI/engine itself supports and would honor it.

Net effect: for any model whose catalogue entry sets a non-default default_service_tier (e.g. gpt-5.6-sol → priority, displayed as "Fast"), there is no way to durably override it to default via config — the Desktop app reverts it on every launch.

Repro:

  1. Quit the Codex Desktop app.
  2. Add service_tier = "default" to ~/.codex/config.toml (top-level key).
  3. Confirm it persists in the file while the app is quit.
  4. Relaunch the app.
  5. Re-read config.toml — the key is gone within seconds of launch.

Versions: bundled codex-cli 0.145.0-alpha.30; client_version 0.145.0 in ~/.codex/models_cache.json. macOS.

Expected: an explicit, documented, engine-supported service_tier config value should survive the Desktop app's own config load/save cycle, letting users durably override a model catalogue's default_service_tier (and its UI label, e.g. "Fast") to default.

Actual: the Desktop app's own settings serializer silently discards the key on every launch, since its internal settings model doesn't track that field.

View original on GitHub ↗

1 Comment

void0xsasha · 2 hours ago

Windows reproduction / corroborating evidence (2026-08-28)

I am seeing the same class of behavior on Codex Desktop for Windows.

Environment:

  • Codex Desktop app version exposed in runtime config: 26.820.71523
  • Windows 11 / x64
  • model: gpt-5.6-sol
  • reasoning: high
  • project-local config explicitly pins service_tier = "default" and fast_mode = false

Observed global config state after Desktop use:

  • ~/.codex/config.toml still has fast_mode = false
  • top-level service_tier is absent entirely
  • the explicit global service_tier = "default" that had been configured as a hardening override is no longer present

This was detected because a repository preflight intentionally checks the global Codex config before material work. The preflight stopped the task when it saw the global tier missing. The repository-local config itself was still explicitly default, so the missing key is isolated to the user-global config.

I cannot prove from this single snapshot which process performed the write, so I am not attributing the mutation conclusively yet. I am installing a local file watcher that will record config hashes/timestamps and the relevant tier keys before automatically restoring service_tier = "default"; that should provide exact before/after evidence if Desktop strips it again.

This matters because an absent explicit override can interact with Codex-managed/model-catalog service-tier defaults, while the user intended Standard. It is especially concerning for long-running/high-reasoning tasks because Fast/Priority can materially increase allowance consumption.

Related issues that appear adjacent:

  • #37666 (thread Speed change leaking into global service_tier)
  • #40056 (unexpected default/priority oscillation)
  • #39894 / #30407 (subagent service-tier behavior)

Expected: an explicit user-global service_tier = "default" should remain durable across Codex Desktop load/save/restart cycles on Windows as well as macOS.