Summary

After the OpenAI/Codex route unification in 2026.6.1, a 5.28-era Codex context override can be lost: openai/gpt-5.5 running through the Codex runtime no longer reads models.providers.openai-codex.models[].contextTokens, so sessions can fall back to the Codex runtime default 272000 instead of the configured ~1M cap.

This looks like a regression of the behavior fixed in #77858 / #77861, not a general session-context preservation issue.

Real environment observed

• Windows OpenClaw node upgraded from 2026.5.28 to official 2026.6.1
• Route after migration: openai/gpt-5.5 with agentRuntime.id = "codex"
• Before the upgrade, the local config used a 5.28-style override under models.providers.openai-codex.models[]:
  • id: "gpt-5.5"
  • contextTokens: 1050000
• After the 6.1 migration/repair, the active context display fell back to ~272k.

A read-only config probe after the upgrade showed no gpt-5.5 context override under the canonical models.providers.openai.models[] entry, so the 5.28-era override was not available to the 6.1 resolver.

Why this matters

#77861 intentionally made native Codex runs honor Codex OAuth context overrides. Its real behavior proof used exactly this kind of setup:

• openai/gpt-5.5
• Codex runtime
• models.providers.openai-codex.models[].contextTokens: 1000000
• expected /status / agentMeta.contextTokens around 1.0m

In 2026.6.1, OpenAI/Codex provider ids were unified. That is fine as a route/auth model, but legacy context-window metadata needs either migration or a compatibility fallback. Otherwise existing installs can silently lose their larger configured Codex context budget.

Source-level repro on current main

Current main resolves the context config provider for OpenAI routes to openai:

resolveContextConfigProviderForRuntime({ provider: "openai", runtimeId: "codex" })
// => "openai"

With a legacy 5.28-style config where the override still lives under openai-codex, the current resolver misses it and returns the fallback/default:

{
  "models": {
    "providers": {
      "openai-codex": {
        "models": [
          { "id": "gpt-5.5", "contextTokens": 1050000, "contextWindow": 400000 }
        ]
      },
      "openai": { "models": [] }
    }
  }
}

Observed with a local probe on current main:

{"name":"cfgLegacy","contextConfigProvider":"openai","tokens":272000}

If the same override is placed under canonical models.providers.openai.models[], the resolver returns the expected cap:

{"name":"cfgCanonical","contextConfigProvider":"openai","tokens":1050000}

Expected behavior

Upgrading/repairing a 5.28-era config should preserve the effective Codex context cap for openai/gpt-5.5 + codex runtime.

Either of these would be reasonable:

1. migrate the relevant models.providers.openai-codex.models[].contextTokens/contextWindow metadata to the canonical models.providers.openai.models[] entry; or
2. compatibility-read legacy openai-codex context metadata when the canonical openai model entry has no explicit context override.

Actual behavior

A legacy Codex override can be ignored after 6.1 provider unification, so the active budget can fall back to 272000.

Scope / non-goals

• This is not about changing the default Codex runtime cap.
• This is not about expanding the native Codex context engine or projection logic.
• This is not about Preserve session context and durable Telegram progress #84828-style durable Telegram progress/session-context persistence.
• The narrow scope is preserving existing configured context-window metadata across the OpenAI/Codex provider unification.