[Windows 26.903.9818.0] Desktop ships app-server 0.153.4, rejects its own feature keys and marks connected Remote state as failed

Environment

• Codex Desktop: 26.903.9818.0 from Microsoft Store
• Windows 11 x64
• Fresh launch after the Store update
• Desktop-owned app-server reports 0.153.4
• No model request was needed to reproduce

Issue

The updated Desktop launches successfully, but its own app-server rejects experimental feature keys sent by the Desktop and that warning is then propagated into Remote Connections as a connection failure even though the transport is connected.

Sanitized startup sequence:

Current reported app-server version: currentVersion=0.153.4
ignoring invalid experimental feature enablement keys:
apps_mcp_path_override, local_thread_store_compression

remote_connections.connection_state_changed
  error.code=connection-failed
  state=connected

remote_connections.manager_state_set
  nextError=connection-failed
  nextState=connected

At the same time, the app-server handshake succeeds and the Desktop's remoteControl/enable request returns with errorCode=null.

The contradiction is therefore reproducible locally: the host is connected and Remote Control enablement succeeds, but the manager carries a connection-failed error sourced from incompatible feature configuration.

Version-skew evidence

The Desktop copied and spawned its bundled Windows engine from the updated package, and logs explicitly record:

coreRuntimeInUse=false
source=copied

The Desktop also receives runtime-install metadata advertising codex-primary-runtime bundle 26.909.12148, but that runtime is not installed/selected for this app-server during the observed launch. The running Desktop-owned app-server remains 0.153.4.

This version skew is also operationally relevant because stable Codex 0.154.0 contains rollout/history fixes not present in 0.153.4; an already-affected 0.153.4 paginated thread on this machine remained unrepaired after updating and launching 26.903.9818.0. That history defect is tracked separately in #43142; I am not claiming the Remote warning causes that corruption.

Expected behavior

A released Desktop package should either:

1. ship/select an app-server compatible with the feature keys the Desktop sends, or
2. omit unsupported feature keys for the bundled app-server version.

A non-fatal unsupported-feature warning should not be surfaced as connection-failed while the connection state is connected and remoteControl/enable succeeded.

Notes

• The Desktop otherwise launches normally.
• This report does not include prompts, conversation content, credentials, account identifiers, private paths, or raw configuration.
• Similar warning strings appear in older/cross-platform reports, but I found no issue specifically covering the current Windows Store package 26.903.9818.0 with the connected+failed state contradiction.

Start with the Desktop-owned app-server startup and the handling of experimental feature keys, then trace remote_connections.connection_state_changed and remote_connections.manager_state_set. Reproduce the Windows Store launch with app-server 0.153.4 and inspect the remoteControl/enable result. Done means compatible feature configuration is used and a connected state is not marked with a connection-failed error from a non-fatal warning.