Codex Desktop "Open in VS Code" drops sshPort for manually added SSH connections

Codex Desktop "Open in VS Code" drops sshPort for manually added SSH connections

Summary

Codex Desktop supports manually added SSH connections with a dedicated SSH port field, but when a remote file is opened in VS Code, the VS Code Remote-SSH launch path appears to discard that port information.

As a result, a Codex-managed SSH connection that works correctly inside Codex can fail or open the wrong target in VS Code unless the user duplicates the same connection into their personal ~/.ssh/config.

That should not be required. If Codex owns the manual SSH connection configuration, Codex should pass or bridge that full configuration when launching VS Code Remote-SSH.

Environment

• Codex Desktop: 26.608.12217 (3722)
• Platform: macOS
• Remote connection type: Codex Desktop manually added SSH connection
• Remote host: Linux SSH host
• SSH port: non-default port, for example 45022
• Editor target: VS Code / VS Code Remote-SSH

Reproduction

1. In Codex Desktop, go to Settings > Connections.
2. Add an SSH connection manually.
3. Set:

• Host: example.com
• User: user
• SSH port: 45022
• Identity file: optional, if needed

1. Connect successfully in Codex Desktop.
2. Open a remote project and start a thread.
3. Click a remote file and choose to open it in VS Code.

Expected behavior

Codex should open VS Code Remote-SSH using the full Codex-managed SSH connection information, including:

• host
• user
• SSH port
• identity file, if configured

The user should not need to manually duplicate the same connection into ~/.ssh/config.

Actual behavior

The Codex connection itself can work, but the VS Code open-file handoff appears to generate a VS Code Remote authority like:

ssh-remote+user@example.com

without preserving the configured SSH port.

For non-default SSH ports, VS Code then lacks the information needed to connect to the same target that Codex is already using.

Why the SSH config workaround is not acceptable

Telling users to add a duplicate entry to ~/.ssh/config is only a workaround, not a product-level fix.

Codex Desktop already has a first-class manual SSH connection model and UI. Once the user has provided host/user/port/identity in Codex, the app should treat that as the source of truth for downstream integrations.

Requiring ~/.ssh/config duplication has several problems:

• It dirties user-owned SSH configuration for a connection Codex already knows about.
• It creates two sources of truth that can drift.
• It makes manual Codex connections second-class compared with discovered SSH config aliases.
• It surprises users because the connection works in Codex but not when opening the same remote file in VS Code.

Local code evidence

From the packaged Codex Desktop main-process bundle, the VS Code Remote launch path appears to build arguments around:

--remote ssh-remote+<authority>
--folder-uri vscode-remote://<authority>/<path>
--file-uri vscode-remote://<authority>/<path>

The authority construction appears to prefer an SSH alias, or otherwise fall back to parsing the last token of the terminal command:

function mO(e) {
  return `ssh-remote+${hO(e)}`
}

function hO(e) {
  if (e.kind === `ssh`) {
    let t = gO(e)
    if (t) return t
  }
  return e.name?.trim() || _O(e.id)
}

function gO(e) {
  let t = e[bg]
  let n = typeof t?.sshAlias == `string` ? t.sshAlias.trim() : ``
  if (n.length > 0) return n
  let r = Array.isArray(e.terminal_command) ? e.terminal_command.at(-1) : null
  let i = typeof r == `string` ? r.trim() : ``
  return i.length > 0 ? i : null
}

For a command like:

ssh -p 45022 user@example.com

the last token is only:

user@example.com

The -p 45022 part is lost.

The debug UI also shows that Codex connection objects know about SSH port, so this looks like the bridge to VS Code is not consuming the manual connection's sshPort.

Suggested fix

Codex should not require users to modify ~/.ssh/config.

Instead, when opening a manually configured SSH connection in VS Code Remote-SSH, Codex should either:

1. Generate a Codex-managed temporary SSH config/alias under Codex's own application support directory and pass that alias to VS Code, or
2. Use a VS Code Remote-SSH supported invocation path that includes the equivalent host/user/port/identity information.

The first option seems robust:

Host codex-managed-<connection-id>
  HostName example.com
  User user
  Port 45022
  IdentityFile ...
  IdentitiesOnly yes

Then launch VS Code with:

--remote ssh-remote+codex-managed-<connection-id>

This keeps user SSH config clean, preserves Codex as the source of truth, and makes manual SSH connections behave consistently with discovered SSH config aliases.

Impact

This makes remote workflows feel broken in a very confusing way:

• Codex can connect to the remote host.
• Codex can read/write remote files.
• The user clicks "Open in VS Code".
• VS Code does not receive the same connection details.

That is a handoff bug, not a user configuration problem.

Please treat manual SSH connection data as first-class when launching external editors.