2 Commits

• Improve codex remote-control CLI UX (#22878)

  ## Description
  
  This PR makes `codex remote-control` behave like a foreground CLI
  command by default. Running it now starts remote control, waits for
  readiness, prints a clear status message with the machine name, and
  stays alive until Ctrl-C.
  
  Users who want daemon behavior can use `codex remote-control start`, and
  `codex remote-control stop` now prints concise human-readable output.
  `--json` remains available for scripts.
  
  Implementation-wise, this now verifies the real app-server state instead
  of just assuming startup worked. The CLI starts or connects to
  app-server, probes its control socket, calls the `remoteControl/enable`
  API, and waits for the remote-control status response/notification
  before printing success.
  
  For daemon mode, `codex remote-control start` also reports which managed
  app-server binary was used, including its path and best-effort `codex
  --version`, so failures are easier to diagnose.
  
  ## Examples
  
  Example output:
  ```
  > codex remote-control
  Starting app-server with remote control enabled...
  This machine is available for remote control as com-97826.
  Press Ctrl-C to stop.
  ```
  
  Error case using daemon (currently expected based on our publicly
  released CLI version):
  ```
  > ./target/debug/codex remote-control start
  Starting app-server daemon with remote control enabled...
  Error: app server did not become ready on /Users/owen/.codex/app-server-control/app-server-control.sock
  
  Daemon used app-server:
    path: /Users/owen/.codex/packages/standalone/current/codex
    version: 0.130.0
  
  Managed app-server stderr (/Users/owen/.codex/app-server-daemon/app-server.stderr.log):
    error: unexpected argument '--remote-control' found
    
    Usage: codex app-server [OPTIONS] [COMMAND]
    
    For more information, try '--help'.
  
  Caused by:
      0: failed to connect to /Users/owen/.codex/app-server-control/app-server-control.sock
      1: No such file or directory (os error 2)
  ```
  
  ## What changed
  
  - `codex remote-control` now runs remote control in the foreground and
  prints a Ctrl-C stop hint.
  - `codex remote-control start` starts the daemon and waits for remote
  control readiness before reporting success.
  - `codex remote-control stop` reports stopped/not-running status in
  plain language.
  - Startup failures now include recent managed app-server stderr to make
  daemon issues easier to diagnose.
  - Added coverage for CLI output, readiness waiting, foreground shutdown,
  and stderr log tailing.

  Owen Lin · 2026-05-18 13:39:02 -07:00
  1752f374a8
• [daemon] Add app-server daemon lifecycle management (#20718)

  ## Why
  
  Desktop and mobile Codex clients need a machine-readable way to
  bootstrap and manage `codex app-server` on remote machines reached over
  SSH. The same flow is also useful for bringing up app-server with
  `remote_control` enabled on a fresh developer machine and keeping that
  managed install current without requiring a human session.
  
  ## What changed
  
  - add the new experimental `codex-app-server-daemon` crate and wire it
  into `codex app-server daemon` lifecycle commands: `start`, `restart`,
  `stop`, `version`, and `bootstrap`
  - add explicit `enable-remote-control` and `disable-remote-control`
  commands that persist the launch setting and restart a running managed
  daemon so the change takes effect immediately
  - emit JSON success responses for daemon commands so remote callers can
  consume them directly
  - support a Unix-only pidfile-backed detached backend for lifecycle
  management
  - assume the standalone `install.sh` layout for daemon-managed binaries
  and always launch `CODEX_HOME/packages/standalone/current/codex`
  - add bootstrap support for the standalone managed install plus a
  detached hourly updater loop
  - harden lifecycle management around concurrent operations, pidfile
  ownership, stale state cleanup, updater ownership, managed-binary
  preflight, Unix-only rejection, forced shutdown after the graceful
  window, and updater process-group tracking/cleanup
  - document the experimental Unix-only support boundary plus the
  standalone bootstrap/update flow in
  `codex-rs/app-server-daemon/README.md`
  
  ## Verification
  
  - `cargo test -p codex-app-server-daemon -p codex-cli`
  - live pid validation on `cb4`: `bootstrap --remote-control`, `restart`,
  `version`, `stop`
  
  ## Follow-up
  
  - Add updater self-refresh so the long-lived `pid-update-loop` can
  replace its own executable image after installing a newer managed Codex
  binary.

  Ruslan Nigmatullin · 2026-05-08 16:51:16 -07:00
  0c8d42525e