Codex Model Overrides Leaking Into Telegram Is a Session-Governance Bug, Not a Settings Quirk

Codex Model Overrides Leaking Into Telegram Is a Session-Governance Bug, Not a Settings Quirk

Model selection is not a preference anymore. In an agent runtime, it is policy.

That is why OpenClaw issue #88490 is more interesting than the symptom first suggests. The report says a Codex model/auth-profile choice can pin an unrelated main session — specifically a Telegram direct chat — to the Codex-selected model. The concrete case: a Telegram session normally using openai/gpt-5.5 ends up pinned to github-copilot/claude-sonnet-4.6 after the user selects that Codex model with a secondary OAuth account. /status then warns: Reason: session override and This session is pinned to github-copilot/claude-sonnet-4.6; config primary openai/gpt-5.5 will apply to new/unpinned sessions.

The workaround is manual: run /reset. That is acceptable for a developer debugging a nightly build. It is not acceptable as a governance story for agents that span chat apps, coding surfaces, OAuth accounts, and provider bills.

The problem is not the wrong model. It is the wrong owner.

The report’s reproduction path is short. Start with a main Telegram direct session on the default model, openai/gpt-5.5. Open Codex. Select a model using a different auth profile, in this case a GitHub Copilot-backed Claude Sonnet model through a secondary OAuth account. Return to Telegram. Run /status. The Telegram session now appears to have a session-level model override that the user did not intentionally set from Telegram.

ClawSweeper triaged it as P2 with impact:session-state and impact:auth-provider, plus needs-product-decision and needs-live-repro. That caution is fair: the exact Codex-to-Telegram trigger still needs focused regression proof. But the review also keeps the issue open because source inspection shows plausible persistence paths. The recommended fix shape is the important part: Codex model and auth-profile selections should persist only in the Codex app-server binding or an explicit Codex session key. Telegram should show a session override only after an intentional OpenClaw session-level model selection.

That is the core bug class. A setting created in one surface appears to be owned by another surface. The model did not merely change; the ownership boundary blurred.

Agent platforms keep using the word “session” as if it names one thing. It does not. There is a human-facing conversation session. There is a channel session for Telegram, Slack, Discord, iMessage, or WhatsApp. There is a model runtime session. There is a coding-agent app-server binding. There is an auth-profile selection. There is a transcript ID. There may be a command-target session, a subagent requester session, and a restored continuation after restart. These objects are related, but they are not substitutes for each other.

If Codex writes model state under a key that Telegram later interprets as its own override, the platform has collapsed scopes that users mentally keep separate. That is how “settings quirk” bugs become operational incidents.

The bill, the audit log, and the next message all care

It is tempting to downplay this as a weird /status annoyance. The next reply uses the wrong model, the user notices, they reset, everyone moves on. That framing misses why model routing now belongs to runtime governance.

A leaked override can move a chat from one provider to another. It can move usage from one billing account to another. It can change the capability envelope: tool-calling behavior, context limits, safety policies, prompt compatibility, file handling, latency, and cost. It can change which vendor sees the next message. In the reported case, the boundary crosses from default openai/gpt-5.5 to github-copilot/claude-sonnet-4.6 via a secondary OAuth profile. That raises several questions operators should not have to reverse-engineer from a warning line: Who set this override? From which surface? Which account pays? Was it meant to apply globally, per session, per Codex binding, or only for one coding task?

The answer cannot be “because the same agent identity touched both surfaces.” That is too coarse. Agents are becoming multi-surface workloads. They write code in one tab, answer Telegram in another, monitor Slack, run cron jobs, spawn subagents, and hold state across restarts. Shared identity is useful for continuity, but shared mutable settings are dangerous when the setting controls provider, auth, cost, and data routing.

The fix pattern is old systems engineering: scope state to the narrowest owner that can explain it. Codex UI selections belong to Codex. Telegram overrides belong to Telegram or to the explicit OpenClaw session the user is commanding. Global defaults belong to config. Temporary command overrides should expire or carry a visible owner. If a state mutation is intentionally shared, emit that intent in the audit trail.

/status is the obvious surface to improve. “Reason: session override” is useful; “session override set by Codex binding at 00:43 UTC using auth profile github-copilot:secondary” would be much better. The ideal status output tells the operator the owner, age, origin surface, auth profile, and reset target. A reset command should also be scoped. Clearing every bit of session state is a blunt instrument when the actual problem is a single leaked model pin.

This rhymes with the Gemini transport bug

The timing matters. The same evening, OpenClaw also received issue #88480, where a configured Google Gemini model can apparently route through the generic OpenAI Responses transport. One bug is about provider-to-transport resolution. The other is about Codex model state escaping into Telegram. Different symptoms, same product lesson: model identity, provider identity, auth identity, and session scope have become operational facts. They need explicit contracts.

This is where coding-agent comparison charts usually underperform. They count models and tools, then call the platform flexible. Flexibility is not enough. The serious question is whether the runtime can prove which model will answer, which provider will receive the prompt, which credentials authorize the call, which surface set the override, and how to unwind it without nuking unrelated context. That is what enterprise buyers will ask after the first surprise bill or audit exception.

For engineers building or operating similar systems, the checklist is concrete. Add regression tests that mutate Codex model state and assert unrelated channel sessions remain unpinned. Log the actor and surface that set each override. Put override owner and age in status views. Add a targeted reset path. Consider TTLs for interactive model experiments. Treat secondary OAuth profiles as separate security principals, not just convenient buckets of tokens. And fail closed when a model override would cross from a coding surface into a chat surface without an explicit user action.

None of this is glamorous. That is the point. Once agents become durable, cross-channel, and provider-diverse, settings become state, state becomes policy, and policy needs ownership.

The editorial read: OpenClaw does not have a Telegram bug here so much as a session-governance smell. Selecting a model in a tool should not silently rewrite the behavior of a human’s chat session. Model choices now carry cost, privacy, and capability implications. Treat them accordingly.

Sources: GitHub issue #88490, OpenClaw v2026.5.27 release, related provider-routing issue #88480