Remote Control enrollment never completes on WSL2 — pairing unavailable, connection errored (CLI 0.154.0)

Same failure on WSL2 with a clean install and a fresh hostname, so this is not specific to Windows. Details below.

Codex CLI 0.154.0, standalone install, Ubuntu on WSL2, Windows 11 26200.

codex remote-control start intermittently succeeds — reporting "This machine is available for remote control as paul-wsl" — and otherwise fails with "Remote control is enabled on paul-wsl but the connection is errored". Either way, codex remote-control pair always fails with remoteControl/pairing/start failed: remote control pairing is unavailable until enrollment completes. The Codex desktop app shows the same state as "Kopplungscode nicht verfügbar".

Ruled out:

• Proxy: env | grep -i proxy is empty, and unsetting all proxy variables changes nothing. (Per the closing comment on #41549.)
• Auth: fresh codex login --device-auth, successful.
• Host identity: set a unique WSL hostname via /etc/wsl.conf to avoid reusing a previously stuck enrollment record. The new name is reported correctly; same failure.
• Competing instances: Windows Codex desktop app and Windows app-server daemon fully stopped.
• Install type: switched from npm @openai/codex to the standalone installer, as instructed by the daemon error.
• Timing: start and pair run as separate commands with 30s in between.

No daemon logs are produced at all — ~/.codex/log/ contains only codex-login.log, and RUST_LOG=debug codex remote-control start prints nothing beyond the normal output, so there is no error detail to attach. That absence may itself be a bug.

On the same machine, native Windows fails one layer earlier with socket directory is not private to the current user, although the directory ACL is correct (owner is the current user, single full-control ACE). WSL2 gets past that point and then fails at enrollment.

Related: #41549 (closed as a proxy issue — not applicable here), #30372.

Reproduce the failure with codex remote-control start and codex remote-control pair on WSL2, then inspect ~/.codex/log/ and the output under RUST_LOG=debug. Compare the WSL2 enrollment failure with the native Windows socket-permission failure; done means identifying the enrollment or connection cause and defining a reliable pairing result with useful diagnostics.