Repository navigation
shell-integration: fix ssh-env SetEnv clobbering user SSH config - #11518
Merged
Merged
Conversation
Contributor
|
Hi @j0hnm4r5, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically. See https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md for more details. |
Contributor
|
!vouch |
Merged
ghostty-vouch Bot
added a commit
that referenced
this pull request
Mar 15, 2026
Triggered by [comment](#11518 (comment)) from @jparise. Vouch: @j0hnm4r5 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
jparise
approved these changes
Mar 15, 2026
jparise
left a comment
jparise
left a comment
Contributor
There was a problem hiding this comment.
This make sense to me and is a good overall improvement. Thanks!
Contributor
|
@j0hnm4r5 was there more you wanted to iterate on before marking this as "Ready for review"? |
Contributor
Author
|
Sorry, I wasn't expecting this to get seen/vouched so quickly! I just double checked the code and a few SSH connections and I think we're good; I'll mark it as ready. |
j0hnm4r5
marked this pull request as ready for review
March 16, 2026 05:27
rjwittams
pushed a commit
to rjwittams/ghostty
that referenced
this pull request
Apr 1, 2026
Triggered by [comment](ghostty-org#11518 (comment)) from @jparise. Vouch: @j0hnm4r5 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
christmic
pushed a commit
to christmic/Sylvander
that referenced
this pull request
Aug 12, 2026
Triggered by [comment](ghostty-org/ghostty#11518 (comment)) from @jparise. Vouch: @j0hnm4r5 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
mitchellh
added a commit
that referenced
this pull request
Oct 26, 2026
`+ssh` passed `-o SetEnv=TERM=...` to ssh. ssh only uses the first SetEnv it finds, so the one on the command line replaced every SetEnv entry in the user's ssh config. This brings back the bug that #11518 fixed in the old shell integration wrapper, now in `+ssh` (#12582). `TERM` was also only set with `--forward-env`, so `--forward-env=false` (what `ssh-terminfo`-only users get) left the inherited `TERM=xterm-ghostty` in place even when the terminfo install failed. ssh sends the SetEnv entries in the user's ssh config again, and a failed terminfo install falls back to `xterm-256color` like it did in 1.3.1, no matter which `ssh-*` features are enabled. `TERM` is now set in the environment of the ssh process instead of with SetEnv, the same way the 1.3.1 wrapper did. ssh sends `TERM` on its own when it opens a remote terminal, so the server doesn't need `AcceptEnv TERM`. This happens whenever `--forward-env` or `--terminfo` is enabled. With both disabled, ssh runs with the user's environment unchanged. The `+ssh` help is updated to explain how `TERM` is chosen. Docs: https://man.openbsd.org/ssh_config#SetEnv
jcollie
pushed a commit
to jcollie/ghostty
that referenced
this pull request
Oct 26, 2026
`+ssh` passed `-o SetEnv=TERM=...` to ssh. ssh only uses the first SetEnv it finds, so the one on the command line replaced every SetEnv entry in the user's ssh config. This brings back the bug that ghostty-org#11518 fixed in the old shell integration wrapper, now in `+ssh` (ghostty-org#12582). `TERM` was also only set with `--forward-env`, so `--forward-env=false` (what `ssh-terminfo`-only users get) left the inherited `TERM=xterm-ghostty` in place even when the terminfo install failed. ssh sends the SetEnv entries in the user's ssh config again, and a failed terminfo install falls back to `xterm-256color` like it did in 1.3.1, no matter which `ssh-*` features are enabled. `TERM` is now set in the environment of the ssh process instead of with SetEnv, the same way the 1.3.1 wrapper did. ssh sends `TERM` on its own when it opens a remote terminal, so the server doesn't need `AcceptEnv TERM`. This happens whenever `--forward-env` or `--terminfo` is enabled. With both disabled, ssh runs with the user's environment unchanged. The `+ssh` help is updated to explain how `TERM` is chosen. Docs: https://man.openbsd.org/ssh_config#SetEnv
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Ghostty's
ssh-envshell integration uses-o "SetEnv COLORTERM=truecolor"when wrapping SSH commands. OpenSSH treats command-line-o SetEnvoptions as replacements for allSetEnventries in~/.ssh/config, not additions. This silently drops any user-configuredSetEnvvariables.For example, a user with this in their SSH config:
...would find
MY_VARempty after SSHing through Ghostty withssh-envenabled.Reference: #10871
Fix
Replace
-o "SetEnv COLORTERM=truecolor"with the additive pattern: setCOLORTERM=truecolorlocally before the SSH call and forward it viaSendEnv.SendEnvis additive — it does not clobberSetEnventries in~/.ssh/config.Trade-off:
SendEnvrequiresAcceptEnv COLORTERMon the remote server (unlikeSetEnv). But this was already the case forTERM_PROGRAM/TERM_PROGRAM_VERSION, so it's a consistent and acceptable approach.Changes
All 5 shell integration files updated with the same pattern:
SetEnv COLORTERM=truecoloroption removedCOLORTERMadded to the existingSendEnvoptionCOLORTERM=truecolorset as a local env var on the execute line (soSendEnvhas something to forward)Test plan
ssh-envin Ghostty config:shell-integration-features = ssh-envSetEnv MY_VAR=hellounder a host in~/.ssh/configandAcceptEnv MY_VARin/etc/ssh/sshd_configon the remoteecho $MY_VARshould returnhello(was empty before this fix)echo $COLORTERMreturnstruecolor(requiresAcceptEnv COLORTERM)echo $TERM_PROGRAMstill propagates (sameAcceptEnvrequirement as before)