Local CLI silently reuses stale Remote Control app-server, causing conda env mismatch

What version of Codex CLI is running?

codex-cli 0.141.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.14.0-35-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Terminal.app

Codex doctor report

What issue are you seeing?

When using Codex on Ubuntu, the local Codex CLI appears to reuse a stale app-server process that was previously started by the macOS Codex App Remote Control feature.

The issue is not that the macOS app fails to guess my intended conda environment. I understand that a remote app-server launched by the macOS app may start from the default login/base environment.

The real problem is that after such a remote-control app-server exists, starting Codex CLI locally on Ubuntu from an activated conda environment does not reliably use the current foreground shell environment. Instead, tool execution can be routed through the already-running app-server, which was launched in base.

In my case, I had:

• Foreground local Codex CLI launched from conda activate dl
• Local CLI version: 0.141.0
• Existing app-server version observed earlier: 0.140.0
• Existing app-server environment: base
• Expected development environment: dl

This caused Codex tool execution to use the wrong Python interpreter and dependencies, even though the foreground Codex CLI process itself was started in dl.

After disabling Remote Control in the macOS Codex app and killing all stale Codex processes, running conda activate dl && codex on Ubuntu works correctly: the Codex CLI processes inherit the dl environment, and no stale app-server / proxy processes are created.

So the core issue seems to be stale app-server reuse / lifecycle management across Remote Control and local CLI usage, leading to environment and version mismatch.

What steps can reproduce the bug?

1. On an Ubuntu machine with conda installed, use a non-base environment for development, for example:

conda activate dl

1. Enable Remote Control in the macOS Codex app and connect it to the Ubuntu machine.

1. On Ubuntu, observe that the macOS app starts remote app-server/proxy processes:

ps -ef | grep -i codex | grep -v grep

Example processes:

node /home/user/.npm-global/bin/codex app-server --listen unix://
.../vendor/.../bin/codex app-server --listen unix://
/bin/sh -c ... codex app-server proxy
node /home/user/.npm-global/bin/codex app-server proxy
.../vendor/.../bin/codex app-server proxy

1. Inspect the environment of the app-server/proxy processes:

for pid in $(pgrep -f "codex app-server"); do
  echo "===== PID $pid ====="
  tr '\0' '\n' < /proc/$pid/environ | grep -E 'CONDA|VIRTUAL_ENV|PATH' | head -20
done

In my case, these processes run in base:

CONDA_DEFAULT_ENV=base
CONDA_PREFIX=/home/user/miniconda3
CONDA_PYTHON_EXE=/home/user/miniconda3/bin/python

1. Leave this app-server running, then start Codex CLI locally on Ubuntu from the intended environment:

conda activate dl
codex

1. Use Codex CLI to run Python-related commands or inspect the backend process environment. The foreground CLI is in dl, but tool execution can be routed through the stale app-server that is still in base.

1. Kill all Codex processes and disable Remote Control in the macOS app:

pkill -9 -f "codex app-server"
pkill -9 -f "codex.*desktop-ssh-websocket"
pkill -9 -f "codex"

1. Start Codex CLI directly on Ubuntu again:

conda activate dl
codex

Now the Codex CLI processes correctly inherit dl, and there are no stale app-server / proxy processes.

What is the expected behavior?

When starting Codex CLI locally from an activated shell environment, Codex should not silently reuse a stale app-server that was previously launched by a different frontend such as macOS Remote Control, especially if that app-server has a different environment or version.

Expected behavior:

1. Local Codex CLI should either start/use a backend that matches the current foreground CLI environment, or clearly indicate that it is reusing an existing app-server.

1. If an existing app-server is reused, Codex should detect and warn about environment or version mismatches, for example:

• foreground CLI environment: dl
• reused app-server environment: base
• CLI version: 0.141.0
• app-server version: 0.140.0

1. Local CLI and remote-control app-server lifecycle should be isolated, or there should be a clear way to restart/select the app-server used by local CLI.

1. At minimum, tool execution should not silently run under a different Python/conda environment from the one used to launch the foreground local CLI.

Additional information

Codex CLI version: 0.141.0
Codex app-server version observed previously: 0.140.0
Remote OS: Ubuntu
Local client: Codex macOS app
Python environment manager: conda
Expected env: dl
Actual remote app-server env: base

Related to #27267. That issue focuses on Desktop Remote SSH launching an outdated remote Codex binary/app-server, which can cause protocol/schema errors such as context_compaction / invalid_enum_value.

My issue is related but different: the stale remote-control app-server/proxy is later reused by the local Ubuntu Codex CLI. This causes the foreground local CLI environment and the actual tool backend environment to diverge. In my case, the local CLI was launched from conda env dl, but the reused app-server/proxy was still running in conda base.