OmO 4.16.2 SessionStart migration overrides the Codex GPT-5.6 default with stale GPT-5.5 settings

[sevelee]

Summary

OmO 4.16.2 writes a stale GPT-5.5 profile into existing project .codex/config.toml files during SessionStart. Because project config overrides the user and built-in model defaults, new Codex chats in that project use GPT-5.5 even though current Codex defaults to gpt-5.6-sol.

Environment

• LazyCodex / OmO version: 4.16.2
• Codex CLI version: 0.144.0-alpha.4
• Codex App version: 26.707.3748.0
• OS: Windows 11, build 26200
• Install method: Codex plugin marketplace/cache
• Model expected from current Codex: gpt-5.6-sol

Repository Decision

• Target repository: code-yeongyu/lazycodex
• Why this belongs here: the write is performed by the OmO SessionStart hook and disappears when OMO_CODEX_CONFIG_MIGRATION_DISABLED=1 is set.
• LazyCodex evidence: latest main at 132a61da36e2e281df97edb90cbf08423df8924c still declares GPT-5.5 in [plugins/omo/model-catalog.json](https://github.com/code-yeongyu/lazycodex/blob/132a61da36e2e281df97edb90cbf08423df8924c/plugins/omo/model-catalog.json#L2-L7). [migrate-codex-config.mjs](https://github.com/code-yeongyu/lazycodex/blob/132a61da36e2e281df97edb90cbf08423df8924c/plugins/omo/scripts/migrate-codex-config.mjs#L68-L76) applies that catalog when root model settings are absent, and the project config path is written on SessionStart.
• Upstream Codex evidence: latest upstream source at 1f0566d3f59298d1bb88820a0d35294f1eeb07ea lists gpt-5.6-sol first in [codex-rs/models-manager/models.json](https://github.com/openai/codex/blob/1f0566d3f59298d1bb88820a0d35294f1eeb07ea/codex-rs/models-manager/models.json#L1-L5). Project .codex/config.toml has higher precedence than user config in [codex-rs/config/src/loader/README.md](https://github.com/openai/codex/blob/1f0566d3f59298d1bb88820a0d35294f1eeb07ea/codex-rs/config/src/loader/README.md#L24-L35).

Reproduction

1. Install or enable OmO 4.16.2.

2. Create a trusted project with an existing .codex/config.toml that has no root model settings, for example:

   [mcp_servers.example]
   enabled = false

3. Leave OMO_CODEX_CONFIG_MIGRATION_DISABLED unset.

4. Start a new Codex session in that project.

5. Read .codex/config.toml or open the new-chat model picker.

Expected Behavior

A project config with no explicit model should continue inheriting the current Codex default, gpt-5.6-sol. OmO should preserve an explicit user model when one exists.

Actual Behavior

The SessionStart migration prepends:

model = "gpt-5.5"
model_context_window = 400000
model_reasoning_effort = "high"
plan_mode_reasoning_effort = "xhigh"

New chats in that project consequently default to GPT-5.5.

Evidence

The latest LazyCodex source was exercised in four isolated fixtures:

• Migration enabled, run 1: the four GPT-5.5 settings were added.
• Migration enabled, run 2: the same four settings were added.
• LAZYCODEX_CONFIG_MIGRATION_DISABLED=1, run 1: the input config remained unchanged.
• LAZYCODEX_CONFIG_MIGRATION_DISABLED=1, run 2: the input config remained unchanged.

Related issues #118 and #120 address GPT-5.6 multi-agent schema handling and explicit model_catalog_json routing. They do not cover the stale root model profile written into project config.

Root Cause

OmO registers scripts/auto-update.mjs as a SessionStart hook. Its config migration scans both the user config and existing project .codex/config.toml files. When a config contains no root model settings, shouldApplyCatalog() selects the bundled current profile. OmO 4.16.2 still bundles 2026-06-04.gpt-5.5-400k-reviewer-high, so it materializes GPT-5.5 into the project layer and overrides Codex's GPT-5.6 default.

Proposed Fix

1. Preserve model inheritance for project configs that contain no explicit root model settings.
2. Update the bundled managed profile from GPT-5.5 to the current supported Codex model as an immediate compatibility fix.
3. Resolve the managed default from current Codex model metadata so future model releases do not require a static catalog update.
4. Remove previously managed GPT-5.5 fields when the migration state proves OmO wrote them and the user has not customized them.
5. Add regression tests for project configs containing only MCP, hook, feature, or agent settings.

Verification Plan

• Run SessionStart migration against a project config with no root model and confirm no GPT-5.5 fields are added.
• Start a new Codex chat in that project and confirm the picker defaults to gpt-5.6-sol.
• Run migration twice and confirm it is idempotent.
• Confirm an explicit project model remains unchanged.
• Confirm OMO_CODEX_CONFIG_MIGRATION_DISABLED=1 still suppresses all config migration.
• Confirm GPT-5.6 multi-agent fixes from GPT-5.6: managed multi_agent_v2=false causes reserved collaboration.spawn_agent schema error #118 and Respect model_catalog_json for explicit subagent routing #120 remain intact.

---

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated

[andms9412-debug]

Reconfirmed on current main at bb8764c (marketplace v4.16.3): the stale profile is still reachable through the bootstrap worker itself, independently of the project migration path described above.

Isolated plugins/omo/components/bootstrap/dist/cli.js setup results:

blank config:
model = "gpt-5.5"
model_context_window = 400000
model_reasoning_effort = "high"
plan_mode_reasoning_effort = "xhigh"

existing explicit config:
model = "gpt-5.6-sol"
model_reasoning_effort = "ultra"
(unchanged)

This narrows the current behavior: v4.16.3 does not overwrite an already explicit GPT-5.6 profile in this bootstrap path, but fresh/blank configs still receive the stale GPT-5.5 fallback. The current model-catalog.json also still declares that GPT-5.5/400K managed profile.

A regression test should therefore cover both cases: preserve inheritance/blank root settings, and preserve an explicit user-selected model. Resolving the managed default from current Codex metadata would avoid another static-catalog migration on the next model release.

Tag: lazycodex-generated