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

Open
#33,750 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
rust

Research direction

Start with the codex app-server --listen unix:// SSH workflow and the codex remote-control start and codex remote-control pair --json entry points. Trace their app-server lifecycle and management checks, then verify that local Unix-socket and Remote Control clients can share tasks, approvals, configuration, and session history without interrupting active turns.

Written by the indexing model from the issue text.

Description

app app-server enhancement remote

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

Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.