In tmux, my terminal's vim color scheme changes after connecting then immediately disconnecting from a remote server via ssh. The exact command sequence is:

vim <my_file>  # vim colors correct
ssh <my server> 
exit  # Immediately disconnect
vim <my_file> # vim colors WRONG

Note: No difference was observed between tmux and tmux -2. I also saw no difference in tmux info before and after the ssh connection.

I am unable to determine why connecting/disconnecting via ssh affects how vim runs on my local machine. This only happens with tmux. It does not happen with my normal terminal.

Color Comparison:

Image Comparison of the Terminal

Setup Info:

  • MacOS Mojave 10.14.6
  • Terminal: MacOS 2.9.5
  • Shell: oh-my-zsh
  • tmux: 2.9a (installed via brew)
  • vim: 8.1
  • Vim Package Manager: Vundle
  • Color Scheme: Gruvbox

MWE .zshrc

"     Vundle Start
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'VundleVim/Vundle.vim'
Plugin 'morhetz/gruvbox'
call vundle#end() 
filetype plugin indent on
"     Vundle END

syntax on

colorscheme gruvbox
set background=dark

(Adding set t_Co=256 to .vimrc seemed to have no effect)


set-option -g default-shell /usr/local/bin/zsh
set -g default-terminal "screen-256color"

1 Answer 1


This is probably being caused by an ANSI Escape Sequence in your prompt of the remote server, that is perhaps putting the terminal in a certain mode and not resetting it back to normal when done.

It's hard to tell which sequence exactly might be causing this... Perhaps ESC [ 2m for "low intensity mode"?

The reason why this only happens inside tmux is that tmux implements large part of its own escape sequences, so sometimes it will behave differently from the terminal itself.

In order to further troubleshoot this issue, first try to capture the escape sequences you are getting when you connect to the remote server. You can use the script(1) command to do that:

$ script
$ ssh <my_server>
my_server$ exit
$ exit
Saved output in file `typescript`

You need an extra exit to stop the script session. The characters will be saved in file typescript.

You can then inspect the contents of the file with:

$ cat -v typescript

Which will show the escape sequences in a printable way, so that they don't activate and you can see them. The ESC key is showed as ^[. So if you see a sequence ^[[2m, that's the "low intensity" one I mentioned above.

Even if that's not the actual one that's triggering this problem, you could edit your question to update it with the exact escape sequences you're seeing, that would help us narrow out which one is triggering this particular behavior.

If it's really being caused by escape sequences from the remote server, then check your prompt on that machine to see whether that's what's sending those particular sequences. (In bash, look at $PS1 and perhaps $PROMPT_COMMAND.) You might want to fix them to either stop using that particular sequence, or to reset settings or undo the effects of the particular sequence once done with it.

UPDATE: After using the procedure above to diagnose the issue, we noticed that the cause of the problem was the server-side .zshrc file gruvbox_256palette_osx.sh, which modifies the color palette of the terminal when executed.

The server side has $TMUX unset so the gruvbox script was not using the proper escape sequences, getting the color palette out of sync and producing the difference in colors that was observed here.

  • I checked the typescript output (see a version with personal info removed) and I do not see the soft escape sequence you mention.
    – ZaydH
    Sep 2, 2019 at 3:39
  • There are definitely some interesting escape sequences there, such as ^[Ptmux;^[^[]4;236;rgb:26/24/23^G^[` before the ssh and ^[P^[]4;236;rgb:26/24/23^G^[` after the ssh. It's interesting to notice the former mentions Ptmux while the latter doesn't, so it's maybe updating color values in your actual terminal rather than tmux's idea of the colors?
    – filbranden
    Sep 2, 2019 at 4:07
  • This is almost surely related to your prompt. Looks like it's the same locally and remotely, but remotely it doesn't detect it's inside tmux (perhaps because the $TMUX variable isn't defined?) and this results in it messing up with the colors of the actual terminal running tmux. What's in your prompt?
    – filbranden
    Sep 2, 2019 at 4:11
  • 1
    You are right. I was proceeding under the assumption that settings change in the ssh session were invisible to the original terminal. The server-side .zshrc file was calling gruvbox_256palette_osx.sh. However, the server side has $TMUX unset so the gruvbox script was loading the wrong settings. I am ok with marking this answer as accepted if you agree.
    – ZaydH
    Sep 2, 2019 at 5:26
  • Sure, please mark it as accepted if it solved your problem! I included the part about the gruvbox script in the answer, in order to make it more complete. Cheers!
    – filbranden
    Sep 2, 2019 at 6:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.