[VS Code] Fast mode enabled across restored vscode windows without an explicit opt-in

What version of the IDE extension are you using?

26.820.60940 when Fast first appeared; 26.820.71523 during the long-running task. Both bundled codex-cli 0.150.0-alpha.8.

What subscription do you have?

Pro

Which IDE are you using?

VS Code 1.135.0, Remote WSL

What platform is your computer?

Linux 6.18.40.1-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

After a VS Code crash/restart, Fast mode was active in every restored VS Code window although I had not selected it. service_tier was unset in my configuration at the time.

Fast was also active when I resumed the affected conversation in Codex CLI, which is how I noticed it. I had to disable Fast separately in each VS Code window and the CLI session; it would otherwise have remained enabled.

The rollout confirms Fast was actually applied: affected turns record "service_tier": "priority". One task ran under this setting for approximately 6 hours and 39 minutes and consumed roughly 30% of my weekly allowance.

VS Code indicates Fast with a small monochrome lightning icon in the collapsed model control, but it is easy to miss. The explicit Fast label and 1.5x speed, increased usage warning appear only inside the model-selection menu under Speed.

What steps can reproduce the bug?

This is the observed sequence; I do not yet have a deterministic minimal reproduction:

1. Use Codex in multiple VS Code windows with no explicit service_tier.
2. Crash/restart VS Code and restore the windows.
3. Observe that Fast is active across the restored windows.
4. Resume an affected conversation in Codex CLI and observe Fast there too.
5. Disable Fast in one client; the others still require separate changes.

What is the expected behavior?

If Fast is applied as a managed default:

• Users should receive a prominent notification.
• The active mode should be clearly labeled Fast, preferably with a distinctive color.
• The increased-usage warning should remain visible.
• VS Code should provide an obvious durable global opt-out.

Additional information

I added explicit Standard/disabled-Fast settings only after discovering the incident; they were not present when Fast first appeared.

I can provide sanitized rollout events, extension-host logs, and a screenshot.

Related: #19230, #23104.

No source file or test is named. Start by tracing how restored VS Code windows and Codex CLI preserve the service_tier setting, then try the reported multi-window crash and restart sequence. Done means Fast is not enabled without explicit opt-in and its active state, warning, and opt-out behavior are consistent across clients.