OpenClaw Brings Codex Sessions to Approved Paired Devices, With Model Discovery Before Catalog Refresh

August 21, 2026 delivered a coordinated set of Codex-runtime changes to OpenClaw: a large capability merge on main, a narrowly scoped discovery fix, and a same-day backport so pinned-release operators are not left waiting for the next line.

Codex sessions on approved paired devices

PR #127202 lands support for running Codex sessions on approved paired devices. The change spans the Gateway, the Control UI, the commands layer, documentation, and the file-transfer plugin, and carries upstream’s security-boundary merge-risk flag — the right call for any feature that extends where a managed runtime may execute.

The design intent visible in the merge is consent-gated: devices participate only after explicit approval, rather than by network proximity or account membership alone.

Interpretation: for fleets, this moves Codex execution closer to where work actually happens — a laptop, a workstation, a field device — without opening the runtime to unapproved hardware. The approval list is now part of your security surface; treat changes to it like changes to your auth configuration.

Operator actions

1. Decide the pairing policy before enabling: which devices, owned by whom, revoked how.
2. Audit the approved-device list on a schedule; an approved device is a runtime host.
3. Test one representative Codex session end-to-end on a paired device, including disconnect/reconnect behavior, before fleet rollout.

New account models work before the catalog catches up

PR #127394 addresses a familiar operational lag: the provider exposes a new model through a Codex account before OpenClaw’s provider catalog has been refreshed, and requests for that model could fail three separate ways — an early harness probe running before authentication is prepared, the provider rejecting an unfamiliar model name, and a native route demanding a host credential it should not need.

The merged fix lets an explicitly selected Codex runtime own model discovery and authentication in that narrow case. Scope discipline matters here: the change applies only when Codex is explicitly selected; authored provider credentials, custom endpoints, route-compatibility rules, and configured reasoning capabilities remain authoritative and untouched.

The pinned release gets it the same day

PR #127395 carries the account-model fix onto the pinned release branch without advancing the rest of OpenClaw. Operators holding the frozen line get new-model availability without giving up pinning — continuing the pattern from yesterday’s 0.149 runtime-pin wave, where the project has consistently treated “pinned” as incompatible with “current.”

The chronology is tight and deliberate: #127394 merged to main at 19:30 UTC, and the release backport followed two minutes later.

Operator actions

1. On pinned releases, confirm your build contains the #127395 backport before expecting newly announced account models to resolve.
2. Keep your catalog-refresh cadence regardless; native discovery is a bridge for brand-new models, not a replacement for curated catalog entries.
3. If a new model fails on an updated build, check the three historical failure points in order — early probe, provider acceptance, credential routing — and report which one you hit; upstream’s narrow scoping means regressions should be equally narrow.

What upstream validated

The paired-device PR carries upstream’s proof: sufficient marker with screenshot evidence; the discovery fix documents the three concrete failure paths it eliminates. These are upstream-reported results reviewed against the official merged records; OpenClaw Academy did not execute device pairings or model probes independently.

Bottom line

Together the trio shortens the distance between “the provider shipped something new” and “my fleet can use it,” while keeping the consent and credential boundaries explicit. Upgrade on your normal cadence, but do the pairing-policy review before you switch the feature on — the approval list is the new part of your trust boundary.