Does ChatGPT Desktop forward your SSH agent? Only if your SSH config does, and then Codex shares it

A Hacker News post by DenGorbachev on November 9 put it in one line: "ChatGPT Desktop forwards your SSH agent to remote machines," so the agent running there "can authenticate using your local SSH credentials" and push to your private GitHub repos. A DEV Community write-up by Sam Labbe the same day went further, saying the Codex integration "ships with your SSH agent baked in" through a --forward-ssh-agent flag.

Half of that is right. We downloaded OpenAI's current Linux build of the ChatGPT desktop app and read the code that sets up Remote SSH. The app does not turn on agent forwarding by itself. If your own SSH config forwards your agent to a host, though, the app deliberately hands that agent to the long-running Codex server on the host, so every command Codex runs there can use your keys for as long as you are connected.

What the cited proof actually is

The HN post links to openai/codex PR #28131, "[codex] Refresh SSH agent for app-server proxy," opened by OpenAI's abhinav-oai on June 13. It would have added an opt-in codex app-server proxy --forward-ssh-agent mode. It was never merged. A GitHub Actions bot closed it on June 29 for having "no updates for more than 14 days," and the review thread Labbe describes as engineers "carefully fixing socket-refresh edge cases" consists of two comments from OpenAI's automated reviewer bot and one reply from the author. A search of the public openai/codex repository finds no forwarded-ssh-agent code at all. A contributor who tried to fix a related bug in October came to the same conclusion: the code that does this lives in the closed-source desktop app, not in the open-source CLI.

So the mechanism is real. It just isn't in the PR.

What the desktop app does

We took ChatGPT for Linux 26.1103.60933, the current package in OpenAI's signed APT repository (the .deb we downloaded matched the SHA-256 listed in the repository index), unpacked its app.asar, and found the Remote SSH bootstrap. Before starting or joining the remote Codex app server, the app runs this shell snippet on the host:

if [ -S "${SSH_AUTH_SOCK:-}" ]; then ln -sfn -- "$SSH_AUTH_SOCK" "${CODEX_HOME:-$HOME/.codex}/app-server-control/forwarded-ssh-agent.sock"; elif [ ! -S "${CODEX_HOME:-$HOME/.codex}/app-server-control/forwarded-ssh-agent.sock" ]; then rm -f -- "${CODEX_HOME:-$HOME/.codex}/app-server-control/forwarded-ssh-agent.sock"; fi

It then starts the server in the background with SSH_AUTH_SOCK pointing at that fixed path, and runs the same snippet again on every later proxy connection. The SSH session's agent socket, if it has one, becomes a stable symlink. The server, and every shell and tool it spawns, finds your agent through it.

The SSH command itself, though, is plain. For Remote SSH hosts the app runs ssh -v -o BatchMode=yes (with -T for the proxy connection), a connect timeout and keepalive options, then the host alias from your ~/.ssh/config. There is no -A and no ForwardAgent=yes. That means OpenSSH decides, using your config, and OpenSSH's default is not to forward. The first branch of the snippet only fires if your config forwarded an agent to that host. That matches issue #48914, filed in September by a user whose host has ForwardAgent no: the app still runs the cleanup half of the snippet there, which is how a bastion that filters rm -f ended up breaking their connection.

The one place the app does set the option itself points the other way. Its connection to OpenAI's own cloud machines (host key alias codex-cloud) passes -o ForwardAgent=no explicitly. The only forward the app adds for Remote SSH is a reverse tunnel (-R) to the desktop app's own tool server, which requires a bearer token and is set to ask before tool calls by default.

Why it works this way

The symlink is a fix, and users asked for it. In May, issue #22567 reported that Remote SSH "does not honor ForwardAgent": people with ForwardAgent yes set up deliberately, for private Git dependencies or docker buildx build --ssh default, found their builds failing inside Codex. The reporter traced it to the detached app server keeping the SSH_AUTH_SOCK of the SSH session that first launched it, a socket that disappears when that session ends. The issue, tagged "Papercuts 2026," was closed as completed on July 30. By September, the bootstrap with the stable link was in the app.

The trade-off comes with the design. Ordinary agent forwarding gives the remote host your agent for one session. Here, a single long-lived server holds it for every Codex chat on that host, through a path any process running as that user can find. Two more open issues show the edges. #59694 (November 5) shows that when two desktop clients connect to the same account, the last one to connect replaces the shared link, and one client's dead agent can hang Git operations for the other. #31670 describes a local Codex CLI session on a Linux machine that appeared to pick up the SSH environment of a server that a Mac had started there over Remote SSH. The ~/.code typo in the fallback path reported in #52026 is gone in 26.1103.60933.

Is this a scandal? Not quite. Anyone who enables agent forwarding to a host is already letting processes on that host use their keys while the session is open, and OpenSSH's manual warns about exactly that. What changed is who those processes are: a coding agent that runs commands it chose itself and may be reading prompt-injected text. Whether a particular command can actually reach GitHub also depends on the session's sandbox and approval settings, which we did not test. OpenAI's Remote connections docs show an IdentityFile example and say nothing about agent forwarding either way.

What to check

Run ssh -G <alias> | grep -i forwardagent for each host you use with the app. If it says yes, possibly because of an old Host * block (the app ignores pattern-only hosts when listing them, but OpenSSH still applies their settings), Codex on that host can sign with whatever ssh-add -l lists on your machine. Turn forwarding off for that alias if you don't need it. If you do, give the host its own key or a read-only deploy key, or load your keys with ssh-add -c or on a hardware key so every signature needs your confirmation.