Environment
Observed behavior 1
Running:
printed:
Starting app-server with remote control enabled...
Error: Remote control is enabled on host but the connection is errored.
Workaround
Running:
codex remote-control stop
codex remote-control start
fixed the immediate connection error:
Stopping remote control...
Remote control stopped.
Starting app-server daemon with remote control enabled...
This machine is available for remote control on the host.
However, the daemon reported:
Daemon used app-server:
path: /root/.codex/packages/standalone/current/codex
version: 0.132.0
Expected behavior
After upgrading the active CLI to 0.133.0 via npm, codex remote-control start should either:
- start the app-server using the same Codex executable/version as the invoking CLI/PATH
- update the standalone app-server to the same version
- clearly explain that remote-control intentionally uses a separate standalone app-server and how to update it
Actual behavior
There is a version split:
Active shell CLI:
/root/.local/lib/node_modules/@openai/codex/bin/codex.js
codex-cli 0.133.0
Remote-control app-server daemon:
/root/.codex/packages/standalone/current/codex
codex-cli 0.132.0
Why this matters
The user believes they are running Codex 0.133.0, but remote-control is actually served by 0.132.0. This can hide fixed bugs, introduce inconsistent behavior, and make debugging remote-control failures difficult.
Questions
- Is
codex remote-control expected to follow the invoking executable / PATH?
- Or is remote-control expected to manage a separate standalone app-server under
~/.codex/packages/standalone?
- If the latter, what is the supported update path for that app-server?
- Should
codex remote-control start warn when the app-server version differs from the active CLI version?
Suggested fix
-
Make remote-control daemon resolution follow the invoking Codex executable when possible.
-
Or explicitly document and print that it uses a separate standalone app-server.
-
Add a version mismatch warning, for example:
Warning: active CLI is 0.133.0 but remote-control app-server is 0.132.0.
-
Add a command or documented flow to update the remote-control app-server.
-
Improve recovery when codex remote-control reports:
Remote control is enabled on the host but the connection is errored.
The successful workaround was:
codex remote-control stop
codex remote-control start
Environment
OS: Ubuntu 22.04.5 LTS
Active shell CLI after npm upgrade:
Active shell Codex path:
Observed behavior 1
Running:
printed:
Workaround
Running:
fixed the immediate connection error:
However, the daemon reported:
Expected behavior
After upgrading the active CLI to 0.133.0 via npm,
codex remote-control startshould either:Actual behavior
There is a version split:
Why this matters
The user believes they are running Codex 0.133.0, but remote-control is actually served by 0.132.0. This can hide fixed bugs, introduce inconsistent behavior, and make debugging remote-control failures difficult.
Questions
codex remote-controlexpected to follow the invoking executable / PATH?~/.codex/packages/standalone?codex remote-control startwarn when the app-server version differs from the active CLI version?Suggested fix
Make remote-control daemon resolution follow the invoking Codex executable when possible.
Or explicitly document and print that it uses a separate standalone app-server.
Add a version mismatch warning, for example:
Add a command or documented flow to update the remote-control app-server.
Improve recovery when
codex remote-controlreports:The successful workaround was: