ssh-env shell integration injects -o SetEnv ... and overrides user SetEnv from ~/.ssh/config

[j0hnm4r5]

Issue Description

When Ghostty shell integration enables ssh-env, it wraps ssh and injects -o "SetEnv ..." options. On OpenSSH, providing SetEnv via -o overrides SetEnv entries from ~/.ssh/config, so user-defined per-host SetEnv values are silently dropped.

This breaks standard SSH env forwarding workflows (even when SendEnv/AcceptEnv are configured correctly). Disabling ssh-env and enabling only ssh-terminfo avoids the issue.

Workaround

If Ghostty is configured with shell-integration-features = ssh-terminfo and does not enable ssh-env, then the same ~/.ssh/config SetEnv / SendEnv forwarding works as expected.

Root Cause Hypothesis

Ghostty's ssh-env wrapper injects -o "SetEnv ..." into the ssh command line.

In OpenSSH, SetEnv options provided via -o override config-defined SetEnv entries rather than merging additively. Therefore, user per-host SetEnv entries from ~/.ssh/config are dropped.

Impact

This breaks legitimate OpenSSH workflows that rely on per-host SetEnv (and then SendEnv/AcceptEnv) to provide session metadata to the remote shell. The failure mode is non-obvious unless running with -vvv.

Expected Behavior

Environment variables passed via SetEnv in an SSH Config should be retained on connection.

Actual Behavior

Environment variables passed via SetEnv are dropped.

Reproduction Steps

1. Configure SSH env forwarding

   Client ~/.ssh/config:

   Host example-host
   	HostName 192.0.2.10
   	User example
   	SetEnv EXAMPLE_VAR=example-value

   Server /etc/ssh/sshd_config:

   AcceptEnv EXAMPLE_VAR

   Restart sshd.

2. Enable Ghostty ssh-env

   Ghostty config contains shell-integration-features = ssh-env.

   Connect:

   ssh example-host

   On the remote:

   echo "$EXAMPLE_VAR"

   Expected: example-value
   Actual: empty output (variable not present)

3. Debug confirms user SetEnv is not applied

   Run:

   ssh -vvv example-host

   Observe that the effective invocation includes -o "SetEnv ..." injected by the wrapper, and later the client sets only the injected env values (example):

   Started with: ssh -o "SetEnv COLORTERM=truecolor" ...
   ...
   debug1: Sending environment.
   debug1: channel 0: setting env COLORTERM = "truecolor"
   

   There is no line like:

   channel 0: setting env EXAMPLE_VAR = "example-value"
   

   This indicates the wrapper is overriding the SetEnv EXAMPLE_VAR=... from ~/.ssh/config.

4. Bypass wrapper: system ssh works

   This succeeds:

   /usr/bin/ssh -o 'SetEnv=EXAMPLE_VAR=example-value' -o 'SendEnv=EXAMPLE_VAR' example-host 'printenv EXAMPLE_VAR'

   As does connecting normally from another terminal.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.2.3

Version
  - version: 1.2.3
  - channel: stable
Build Config
  - Zig version   : 0.14.1
  - build mode    : builtin.OptimizeMode.ReleaseFast
  - app runtime   : apprt.Runtime.none
  - font engine   : font.main.Backend.coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

MacOS 26.2

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

shell-integration-features = ssh-env

### Additional Relevant Configuration

_No response_

### I acknowledge that:

- [X] I have reviewed the FAQ and confirm that my issue is NOT among them.
- [X] I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
- [X] I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (` ``` `) on separate lines.

[rhodes-b]

I don't think there is anything ghostty can do in this case then if passing args with -o SetEnv gets rid of the config file ones

I don't think it should go and read the ssh config, the wrapper isn't meant to be perfect its mean to help in alot of situations

[danielwe]

Took a quick look and this is actually pretty easy to fix. Ghostty just has to use SendEnv instead of SetEnv, since SendEnv adds rather than replaces. Basically, replace

ssh -o "SetEnv FOO=bar" user@host

with

FOO=bar ssh -o "SendEnv FOO" user@host

The behavior you're reporting is definitely problematic, so this seems worthwhile to fix.

[jparise]

Implemented in #11518