›_ Codex Issues
Codex Issues / #33750

Allow SSH and Remote Control clients to share the same app-server

Open 💬 2 comments Opened Jul 17, 2026 by Riki-Du
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

An SSH-managed Codex connection and account-based Remote Control should be able to control the same host and share one app-server, but the current lifecycle management makes the two workflows mutually exclusive for one user/CODEX_HOME.

Real-world topology

  • A company MacBook Pro can reach a Coder development host over SSH.
  • A home MacBook Air cannot reach the private SSH network and must use account-based Remote Control.
  • Both Macs need to control the same Coder host, tasks, approvals, configuration, and thread history.

Observed behavior

The Codex App SSH workflow starts:

codex -c features.code_mode_host=true app-server --listen unix://

Attempting to enable Remote Control on the same Coder host with:

codex remote-control start

fails with:

app server is running but is not managed by codex app-server daemon

codex remote-control pair --json then times out. Stopping the SSH-managed app-server would interrupt active tasks, so users are forced to choose one control path.

Expected behavior

A single app-server should support both:

  • SSH/local Unix-socket clients
  • Secure Remote Control relay clients

Both transports should share tasks, approvals, configuration, and the same session database.

Alternatively, codex remote-control start should safely attach to or upgrade an existing SSH-managed app-server without interrupting active turns.

Why current workarounds are insufficient

  • Separate CODEX_HOME instances split task history, authentication, and configuration.
  • Routing the home Mac through the company Mac requires the company Mac and its desktop App to remain online.
  • Replacing Codex App SSH access with Remote Control everywhere removes a useful direct connection path that is available on the corporate network.
  • Ordinary SSH can coexist, but that does not provide the Codex App's SSH project workflow.

Environment

  • Codex/ChatGPT desktop app: 26.715.21425
  • Local bundled CLI: 0.145.0-alpha.18
  • Coder CLI: 0.144.5

Feedback reference

Codex feedback thread ID: 019f6e74-ee12-7ef2-85b9-0a887c31663d

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33556

Powered by Codex Action

MBJinX · 1 month ago

Confirmed workaround: modify the Codex wrapper at /root/.local/bin/codex so Codex Desktop starts the SSH App Server with Remote Control enabled while continuing to use the same history directory.

Add the following logic before executing the real Codex binary:

export CODEX_HOME="/root/.codex"
unset CODEX_SQLITE_HOME

case " $* " in
" --remote-control ") ;;
" app-server "" --listen unix://"*)
set -- "$@" --remote-control
;;
esac

exec /path/to/real/codex "$@"

Make sure /root/.local/bin appears before the NVM Codex path in PATH. After restarting the App Server and running codex remote-control pair, both Codex Desktop and the mobile app can control the same Codex Server and share the same conversation history.