[Bug] Codex config injection unconditionally forces fast_mode = true, ignoring the tri-state fastMode setting #1021

Summary

injectCodexConfig() unconditionally writes [features] fast_mode = true into ~/.codex/config.toml on every ocx init / ocx start / ocx sync (and the fallback profile always says fast_mode = true). That disagrees with the tri-state fastMode setting used on the wire path (OcxConfig.fastMode, src/types.ts):

• fastMode: false — the wire path strips service_tier from outgoing Requests/Responses, but the client-side injection still forces fast_mode = true, so Codex asks for fast mode while the proxy silently removes the tier. The two halves of the setting contradict each other.
• fastMode unset — documented as "passthrough (don't modify what the client sends)", yet injection still adds fast_mode = true (and creates a [features] table in configs that never had one), overriding user-owned settings such as fast_mode = false and conflicting with setups that intentionally run without fast mode.

Expected behavior

The client-side injection should follow the same tri-state semantics as the wire path:

• fastMode: true → ensure fast_mode = true (current behavior).
• fastMode: false → write fast_mode = false (consistent with the wire strip).
• fastMode unset → leave the user's fast_mode untouched and do not add a [features] table if none exists (fast mode becomes opt-in).

The fallback profile (opencodex.config.toml) should mirror the flag too.

Proposed fix

Thread config?.fastMode through ensureFastModeFeature() and buildProfileFile() in src/codex/inject.ts, writing fast_mode = true|false per the setting and no-op when unset, with regression tests for all three states.

Related

• Routed model selection resets to gpt-5.5 because inject always enables Fast Mode #68 observed the same unconditional injection (closed as a coincidence on the reported symptom, but the injection behavior itself remains).
• The wire-side tier gate is handled by the supportsServiceTier capability (fix(responses): gate service tiers by provider capability #860 area); this issue is the client-side counterpart.