Codex CLI on Linux can inherit stale Remote SSH environment after prior Codex Desktop SSH connection

What version of Codex are you using?

Local host / affected agent surface:

codex-cli 0.143.0

Important correction: the affected local machine is Linux and is using Codex CLI. Codex Desktop was running on a different macOS machine and had previously connected to this Linux machine via Remote SSH.

The shell also printed this warning when running codex --version inside the Codex tool environment:

WARNING: proceeding, even though we could not create PATH aliases: Read-only file system (os error 30)

What platforms are involved?

Affected host, where the local Codex CLI session ran:

Linux gregor 7.1.1 #1-NixOS SMP PREEMPT_DYNAMIC Fri Jun 19 11:50:58 UTC 2026 x86_64 GNU/Linux
NixOS
zsh
kitty terminal
1Password SSH agent
Home Manager-managed ~/.ssh/config symlinked into /nix/store

Other machine involved earlier:

macOS machine running Codex Desktop
Codex Desktop previously connected to the Linux host above via Remote SSH

Normal local shell environment on the Linux host for SSH signing:

SSH_AUTH_SOCK=/home/jwilger/.ssh/ssh_auth_sock
readlink -f ~/.ssh/ssh_auth_sock -> /home/jwilger/.1password/agent.sock
TERM=xterm-kitty
SSH_CONNECTION unset
OP_BIOMETRIC_UNLOCK_ENABLED unset

Global Git signing config on the Linux host:

commit.gpgsign=true
gpg.format=ssh
gpg.ssh.program=/nix/store/...-openssh-10.3p1/bin/ssh-keygen
user.signingkey=ssh-ed25519 <public signing key>

What issue are you seeing?

A local Codex CLI session started on the Linux host appeared to attach to, or inherit environment from, a Codex app-server/session that had originally been started via Remote SSH from Codex Desktop on a separate macOS machine. Inside the Codex tool shell, the environment did not match the local Linux desktop shell and SSH/Git signing was broken.

The bad Codex tool environment had SSH/TTY markers like this:

SSH_AUTH_SOCK=/run/user/1000/ssh-agent-switcher.sock
SSH_CONNECTION=<set>
SSH_CLIENT=<set>
TERM=dumb
OP_BIOMETRIC_UNLOCK_ENABLED=false

By contrast, the normal local zsh shell on the same Linux host had:

SSH_AUTH_SOCK=/home/jwilger/.ssh/ssh_auth_sock
readlink -f ~/.ssh/ssh_auth_sock -> /home/jwilger/.1password/agent.sock
SSH_CONNECTION unset
TERM=xterm-kitty
OP_BIOMETRIC_UNLOCK_ENABLED unset

This caused a painful failure mode for Git-backed tooling:

• ssh-keygen -Y sign worked from the normal local shell with the 1Password SSH agent.
• The same operation from Codex CLI hung or failed because OpenSSH tried to talk to /run/user/1000/ssh-agent-switcher.sock.
• No 1Password prompt appeared.
• Git-backed MCP tooling that creates signed commits failed or hung around fetch/sign/push/sync paths.
• Even explicitly testing a filesystem signing key still hung while SSH_AUTH_SOCK was set, because ssh-keygen -Y sign -f <key> contacted the inherited agent socket before using the file key.

After rebooting the Linux host and starting Codex CLI locally again, the Codex tool environment matched the local desktop shell:

SSH_AUTH_SOCK=/home/jwilger/.ssh/ssh_auth_sock
readlink -f ~/.ssh/ssh_auth_sock -> /home/jwilger/.1password/agent.sock
SSH_CONNECTION unset
TERM=xterm-kitty
OP_BIOMETRIC_UNLOCK_ENABLED unset

At that point SSH signing worked again, subject only to the expected Codex sandbox Git-write approvals.

Why I think this is a Codex bug

The surprising part is not merely that Remote SSH had a bad SSH_AUTH_SOCK. The affected session was started locally with Codex CLI on the Linux host, but it still appeared to attach to an app-server/session environment that had SSH-origin state from a previous Codex Desktop Remote SSH connection from a macOS machine.

This looks like Codex app-server/session reuse or attachment can cross local CLI vs Remote SSH client boundaries and preserve stale process environment, especially SSH_AUTH_SOCK, SSH_CONNECTION, TERM, and 1Password-related variables.

Steps that reproduced the failure in practice

I do not yet have a minimal clean-room repro, but the observed sequence was:

1. From a macOS machine running Codex Desktop, connect to this Linux host using Codex Remote SSH.
2. Later, on the Linux host itself, start or attach to a Codex CLI session for a local project.
3. In the Codex CLI tool shell, inspect SSH-related environment:

``sh
printf 'SSH_AUTH_SOCK=%s\nSSH_CONNECTION=%s\nSSH_CLIENT=%s\nTERM=%s\nOP_BIOMETRIC_UNLOCK_ENABLED=%s\n' \
"$SSH_AUTH_SOCK" "${SSH_CONNECTION-}" "${SSH_CLIENT-}" "$TERM" "${OP_BIOMETRIC_UNLOCK_ENABLED-}"
readlink -f ~/.ssh/ssh_auth_sock
``

1. Compare to a normal local terminal shell on the same Linux host.
2. Try SSH signing through Git or directly:

``sh
printf 'test\n' >/tmp/op-sign-test.txt
ssh-keygen -Y sign -f ~/.ssh/<public-or-configured-signing-key> -n git /tmp/op-sign-test.txt
``

Actual result: Codex CLI had a stale/wrong SSH agent environment and signing failed or hung. The normal local shell worked.

Expected behavior

For a local Codex CLI session on a Linux host:

• The Codex tool environment should be derived from the local CLI/session environment, not from a stale Remote SSH app-server/session that was started by Codex Desktop on another machine.
• SSH_AUTH_SOCK should match the local shell's usable agent socket, or be unset with a clear diagnostic.
• Codex should not preserve SSH_CONNECTION/SSH_CLIENT/TERM=dumb into a local CLI session if the session is not actually running under that SSH connection.
• If Codex reuses an app server across local CLI and remote attachment modes, it should either segregate those environments or refresh the process environment when attaching a local project.
• SSH signing through Git should behave like it does in the user's normal local shell, modulo Codex sandbox approval boundaries.

Adjacent issue

This is adjacent to but not the same as #22567. That issue is about Codex Desktop Remote SSH not honoring agent forwarding. This report is about a local Codex CLI session on Linux appearing to inherit or reuse Remote SSH-origin environment from a previous Codex Desktop SSH connection from another machine, causing local SSH signing and MCP/Git workflows to fail.

Workaround

Rebooting the Linux host and starting Codex CLI locally again produced a correct local environment and resolved the stale SSH agent/socket symptoms. That is too blunt to be a reasonable workaround.