I've been using "Oh My Tmux" for years and it's all been great. After doing a brew upgrade today and going from tmux 3.4.1 to 3.5, my tmux went back to looking like the classing green theme with no configuration. Nothing seems to work the way it was for me.
Any ideas on what it could be? Any suggestions?

P.S.: Using Alacritty as my terminal, if that makes any difference

I have a problem with shift+letter bindings in foot terminal, for example default prefix+C (mapped to customize-mode) doesn't work. Following is my settings related to extended keys mode:

❯ tmux display -p '#{client_termtype}'
foot(1.18.1)
❯ tmux display -p '#{extended-keys}'
on
❯ tmux display -p '#{extended-keys-format}'
xterm

in my config:

set -as terminal-features 'foot*:extkeys'

Looks like foot+tmux combo report any shifted letter press as S+letter. If I explicitly do bind-key S-C customize-mode then pressing shift+c works as expected. In command prompt mode pressing shifted letters is ignored unless I press caps lock.

In editor like kakoune which requests extended keys mode as far as I know, pressing shifted letter reported as S+letter instead of plain capital letter.

Following is what I get in extended mode while pressing shift+c:

❯ printf '\033[>4;1m'
❯ cat
^[[27;2;67~

Changing extended-keys-format to csi-u didn't help.

Is there any way to not emit S+letter in extended-keys mode without turning this mode off? Before update in tmux 3.4 there wasn't such an issue.

To troubleshoot further I display pane_key_mode before and after entering extended keys mode:

❯ tmux display -p '#{pane_key_mode}'
VT10x
❯ printf '\033[>4;1m'
❯ tmux display -p '#{pane_key_mode}'
Ext 1
❯ cat
^[[27;2;67~

Quote from the man page:

mode 1 which changes the sequence for only keys which lack an existing well-known representation;
or mode 2 which  changes  the  sequence  for  all  keys.

I suppose shift+c is falling into existing well-known representation category, therefore should be emitted as plain capital C. Please correct me if I'm wrong or if I should report to foot upstream instead.

I'm setting my prefix to Ctrl+` via:

set -g prefix C-@

but as of 3.5 it does no longer work.

$ tmux -V
tmux 3.4
$ tmux display -p '#{client_termtype}'
XTerm(394)
$ tmux display -p '#{extended-keys}'
off
$ tmux display -p '#{extended-keys-format}'

$ tmux -V
tmux 3.5
$ tmux display -p '#{client_termtype}'
XTerm(394)
$ tmux display -p '#{extended-keys}'
off
$ tmux display -p '#{extended-keys-format}'
xterm

Setting extended-keys to on didn't help, neither did adding set -as terminal-features 'xterm*:extkeys'.

Hit this error when starting tmux v3.5:

/root/.tmux/tmux-common.conf:67: invalid style: fg=color235,bg=grey
/root/.tmux/tmux-common.conf:68: invalid style: fg=purple,bg=grey

I have this in tmux conf which works fine with v3.4:

set -g pane-active-border-style 'fg=color235,bg=grey'
set -g pane-active-border-style 'fg=purple,bg=grey'

I was using tmux with the config below:

set-option -sa terminal-overrides ",xterm*:Tc"
set -g mouse on

unbind C-b
set -g prefix C-w
bind C-w send-prefix

# Vim style pane selection
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

# Start windows and panes at 1, not 0
set -g base-index 1
set -g pane-base-index 1
set-window-option -g pane-base-index 1
set-option -g renumber-windows on

# Use Alt-arrow keys without prefix key to switch panes
bind -n M-Left select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up select-pane -U
bind -n M-Down select-pane -D

# Shift arrow to switch windows
bind -n S-Left  previous-window
bind -n S-Right next-window

# Plugins
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'christoomey/vim-tmux-navigator'
set -g @plugin 'tmux-plugins/tmux-yank'
set -g @plugin 'catppuccin/tmux'

run '~/.tmux/plugins/tpm/tpm'

# set vi-mode
set-window-option -g mode-keys vi
# keybindings
bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi C-v send-keys -X rectangle-toggle
bind-key -T copy-mode-vi y send-keys -X copy-selection-and-cancel

bind '"' split-window -v -c "#{pane_current_path}"
bind % split-window -h -c "#{pane_current_path}"

Since 3.5 I experience way slower performance for example when changing pane and extremely slow performance when trying to update plugins using tpm. Using tmux with iTerm2. Any suggestions?

Hit this error when starting tmux v3.5:

/root/.tmux/tmux-common.conf:67: invalid style: fg=color235,bg=grey
/root/.tmux/tmux-common.conf:68: invalid style: fg=purple,bg=grey

I have this in tmux conf which works fine with v3.4:

set -g pane-active-border-style 'fg=color235,bg=grey'
set -g pane-active-border-style 'fg=purple,bg=grey'

@clarkwang This is minimally reproducable with the style bg=grey, caused by a regression in 2d1e934.

@nicm Here is a patch, that fixes the issue:

diff --git a/colour.c b/colour.c
index 0b787acb..5fd91c9c 100644
--- a/colour.c
+++ b/colour.c
@@ -948,7 +948,7 @@ colour_byname(const char *name)
 
 	if (strncmp(name, "grey", 4) == 0 || strncmp(name, "gray", 4) == 0) {
 		if (name[4] == '\0')
-			return (-1);
+			return (0xbebebe|COLOUR_FLAG_RGB);
 		c = strtonum(name + 4, 0, 100, &errstr);
 		if (errstr != NULL)
 			return (-1);

I was using tmux with the config below:

set-option -sa terminal-overrides ",xterm*:Tc"
set -g mouse on

unbind C-b
set -g prefix C-w
bind C-w send-prefix

# Vim style pane selection
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

# Start windows and panes at 1, not 0
set -g base-index 1
set -g pane-base-index 1
set-window-option -g pane-base-index 1
set-option -g renumber-windows on

# Use Alt-arrow keys without prefix key to switch panes
bind -n M-Left select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up select-pane -U
bind -n M-Down select-pane -D

# Shift arrow to switch windows
bind -n S-Left  previous-window
bind -n S-Right next-window

# Plugins
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'christoomey/vim-tmux-navigator'
set -g @plugin 'tmux-plugins/tmux-yank'
set -g @plugin 'catppuccin/tmux'

run '~/.tmux/plugins/tpm/tpm'

# set vi-mode
set-window-option -g mode-keys vi
# keybindings
bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi C-v send-keys -X rectangle-toggle
bind-key -T copy-mode-vi y send-keys -X copy-selection-and-cancel

bind '"' split-window -v -c "#{pane_current_path}"
bind % split-window -h -c "#{pane_current_path}"

Since 3.5 I experience way slower performance for example when changing pane and extremely slow performance when trying to update plugins using tpm. Using tmux with iTerm2. Any suggestions?

I'm having the same problem too (config), and I think that it's because the if-shell command is using the default-shell and not /bin/sh as documented in the man pages (after running set default-shell /bin/sh the pane switching became quick again).

MacOS: Darwin arm 14.6.1
Kitty terminal: 0.36.4
Fish: 3.7.1
Tmux: 3.5

Here is a patch, that fixes the issue:

Applied to OpenBSD now, will be in GitHub later. Thanks!

My custom bindings like control + shift + x stopped working in 3.5.
Well, they still works in kitty but not in Alacritty.

I read in the issues that tmux now uses lower-key characters so I went into alacritty.toml and changed X to x (with proper unicode) and now my bindings work again in tmux. Hope this help Alacritty users 🙂

I'm setting my prefix to Ctrl+` via:

set -g prefix C-@

but as of 3.5 it does no longer work.

$ tmux -V
tmux 3.4
$ tmux display -p '#{client_termtype}'
XTerm(394)
$ tmux display -p '#{extended-keys}'
off
$ tmux display -p '#{extended-keys-format}'

$ tmux -V
tmux 3.5
$ tmux display -p '#{client_termtype}'
XTerm(394)
$ tmux display -p '#{extended-keys}'
off
$ tmux display -p '#{extended-keys-format}'
xterm

Setting extended-keys to on didn't help, neither did adding set -as terminal-features 'xterm*:extkeys'.

OK, seems the solution is either to:

set -g extended-keys off
set -g prefix C-Space

or

set -g extended-keys on
set -g prefix C-`

With 3.5 (brew next-3.6, MacOS Sequioa) new window always starts with sh instead of zsh. Env var SHELL set to zsh. Configuring default-shell doesn't help.

To troubleshoot further I display pane_key_mode before and after entering extended keys mode:

❯ tmux display -p '#{pane_key_mode}'
VT10x
❯ printf '\033[>4;1m'
❯ tmux display -p '#{pane_key_mode}'
Ext 1
❯ cat
^[[27;2;67~

Quote from the man page:

mode 1 which changes the sequence for only keys which lack an existing well-known representation;
or mode 2 which  changes  the  sequence  for  all  keys.

I suppose shift+c is falling into existing well-known representation category, therefore should be emitted as plain capital C. Please correct me if I'm wrong or if I should report to foot upstream instead.

@vbauerster what does your terminal report (outside of tmux) when you press Shift-c? In standard mode (so after printf '\033[>4m'), as well as in mode 1 (so after printf '\033[>4;1m').

OK, seems the solution is either to:

set -g extended-keys off
set -g prefix C-Space

or

set -g extended-keys on
set -g prefix C-`

This is expected. In the "standard" mode, C-Space, C-@, C-2, and C-backtick are all indistinguishable from each other and reported as C0 NUL ASCII control character. Since 3.5 tmux can distinguish them, given that the outside terminal can be switched to mode 2.

OK, seems the solution is either to:

set -g extended-keys off
set -g prefix C-Space

or

set -g extended-keys on
set -g prefix C-`

This is expected. In the "standard" mode, C-Space, C-@, C-2, and C-backtick are all indistinguishable from each other and reported as C0 NUL ASCII control character. Since 3.5 tmux can distinguish them, given that the outside terminal can be switched to mode 2.

Yeah, but 3.5 stopped interpreting C-@ like it used to, despite extended-keys being off.

With 3.5 (brew next-3.6, MacOS Sequioa) new window always starts with sh instead of zsh. Env var SHELL set to zsh. Configuring default-shell doesn't help.

Fixed with set -g default-command /bin/zsh

Hi! Do C-Arrow bindings on resize-pane not work anymore? I'm super new to Linux in general so I'm kinda confused, I've tried this:

bind -r C-Up resize-pane -U
bind -r C-Down resize-pane -D
...

If I omit the C- it works but then it overrides the default select-pane. I also tried with S-Up and M-Up but those don't work at all (even after source-file). This is on a barebones Alpine Linux Ash /bin/sh

I'm not sure if Alt/M-Arrow is supposed to be default but if it is that's also not working in /bin/sh, I think maybe because by default Alt-Arrow changes the virtual terminal

Edit: Oh and the tmux conf is just those 4 lines for the arrows there's nothing else in it
Update I started learning vi and am used to moving around with the letters now, so I was able to figure out a better mapping
Update again Sorry for so many updates lol but I think it might be useful for others learning too, for now I'm actually just gonna try to learn the standard mappings and commands because I want to try tmux in lots of different environments quickly

Yeah, but 3.5 stopped interpreting C-@ like it used to, despite extended-keys being off.

The way tmux represents keys internally has changed as well. C-@, C-Space, etc, all have unique and individually bindable representations. However when extended-keys is set to off, the parent terminal sends the same ASCII code for all of them, and tmux now chooses to store it as C-Space internally.

@vbauerster what does your terminal report (outside of tmux) when you press Shift-c? In standard mode (so after printf '\033[>4m'), as well as in mode 1 (so after printf '\033[>4;1m').

@crzcrz

Only mode 2 triggers escaped sequences. If tmux always request mode 2 from parent terminal then tmux is responsible to handle this. Also not every terminal supports mode 2 unlike foot terminal. Here is the comment from foot terminal maintainer: https://codeberg.org/dnkl/foot/issues/1850#issuecomment-2344834

I've been pouring over the man page and wiki for a while now and my brain is mush. Sorry for asking if it's in there; I can't find it.

Is there any way to float/align/justify the 0th window to the right, so that the windows are ordered in the same way as my numbers row, i.e. 1-0, not 0-9?

@mags-issues

Is there any way to float/align/justify the 0th window to the right, so that the windows are ordered in the same way as my numbers row, i.e. 1-0, not 0-9?

Try the following:

set-option -g base-index 1
set-option -g renumber-windows on
bind-key 0 select-window -t :10

Since 3.5 I experience way slower performance for example when changing pane and extremely slow performance when trying to update plugins using tpm. Using tmux with iTerm2. Any suggestions?

Same here. The pane switching slowdown is making it unusable. I've tried not using the if-shell command and a few other suggestions here but have not yet solved.

MacOS: Darwin arm 14.6.1
Kitty terminal: 0.36.4
Fish: 3.7.1
Tmux: 3.5

EDIT: For anyone with a job that needs it now on Mac, you can revert to 3.4 with

brew uninstall tmux
brew unlink tmux
wget https://raw.githubusercontent.com/Homebrew/homebrew-core/62acbfc97e3148200e86eb38bfc998145c8e1830/Formula/t/tmux.rb
brew install ./tmux.rb

Since the update to 3.5, C-S-Tab no longer works. showkey -a reports ^[[Z, which is the same as just Shift+Tab.

I use this in alacritty.toml:

[[keyboard.bindings]]
chars = "\u001B[27;5;9~"
key = "Tab"
mods = "Control"

[[keyboard.bindings]]
chars = "\u001B[27;6;9~"
key = "Tab"
mods = "Control|Shift"

I've tried set -g extended-keys on and off, but the behavior is the same.

@randomcoder67 if you set extended-keys to always to force mode 1 output, C-Backtab will produce an extended key sequence.

@randomcoder67 if you set extended-keys to always to force mode 1 output, C-Backtab will produce an extended key sequence.

Setting extended-keys to always changed the showkey -a output to ^[[27;6;9~, which is just what it's mapped to in Alacritty, and the same as the output without tmux running.
Unfortunately it still doesn't perform the mapped action (in my case going to the previous window)

What changed in the latest updated that caused the C to be ignored in C-S-Tab?

I'm getting the same sort of issue with C-S-<letter>. I used C-S-[HJKL] for some resizing and movement stuff and now they just report ^H ^J ^K ^L with showkey -a, which seems like they're just C-h etc. now. Oddly, the movement that I had working with C-S-[HJKL] works fine when I'm in nvim but if I navigate out it stops working entirely.

I've tried setting extended-keys to on, off, and always and the behavior is unchanged.

@randomcoder67 if you set extended-keys to always to force mode 1 output, C-Backtab will produce an extended key sequence.

Setting extended-keys to always changed the showkey -a output to ^[[27;6;9~, which is just what it's mapped to in Alacritty, and the same as the output without tmux running. Unfortunately it still doesn't perform the mapped action (in my case going to the previous window)

What changed in the latest updated that caused the C to be ignored in C-S-Tab?

If you are talking about binding C-S-Tab in tmux itself, then try C-BTab.

I'm getting the same sort of issue with C-S-<letter>. I used C-S-[HJKL] for some resizing and movement stuff and now they just report ^H ^J ^K ^L with showkey -a, which seems like they're just C-h etc. now. Oddly, the movement that I had working with C-S-[HJKL] works fine when I'm in nvim but if I navigate out it stops working entirely.

I've tried setting extended-keys to on, off, and always and the behavior is unchanged.

Lose the S in your tmux bindings. So when you mean to bind Ctrl+a, bind it as C-a. If you mean to bind Ctrl+Shift+a, bind it as C-A.

I'm getting the same sort of issue with C-S-<letter>. I used C-S-[HJKL] for some resizing and movement stuff and now they just report ^H ^J ^K ^L with showkey -a, which seems like they're just C-h etc. now. Oddly, the movement that I had working with C-S-[HJKL] works fine when I'm in nvim but if I navigate out it stops working entirely.
I've tried setting extended-keys to on, off, and always and the behavior is unchanged.

Lose the S in your tmux bindings. So when you mean to bind Ctrl+a, bind it as C-a. If you mean to bind Ctrl+Shift+a, bind it as C-A.

Ah, my mistake. I put that in my comment to make it unambiguous that I was using Control + Shift but I forgot that's not syntactically correct for tmux. My actual bindings are C-H etc. Here's that section of my tmux.conf:

set -g @vim_navigator_mapping_left "C-H"
set -g @vim_navigator_mapping_right "C-L"
set -g @vim_navigator_mapping_up "C-K"
set -g @vim_navigator_mapping_down "C-J"

############################################################################
# TPM
############################################################################
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'christoomey/vim-tmux-navigator'

run '~/.config/tmux/plugins/tpm/tpm'

It works perfectly in 3.4 but I can't get it to work at all in 3.5

Ah, my mistake. I put that in my comment to make it unambiguous that I was using Control + Shift but I forgot that's not syntactically correct for tmux. My actual bindings are C-H etc.

OK, if this is the case, can you try the inverse of my advice, and change the likes of C-H to C-S-H in your bindings please?

Shift is quite problematic, because some terminals send it and some don’t, and there’s no way for us to add it when it’s missing.

No dice, sadly. I've tried the following with extended-keys on, extended-keys always, and extended-keys off:

• C-S-h
• C-S-H
• C-H

They all show up in tmux as C-h it would seem. showkeys -a is still giving me ^H when I type them (and same for the other letters).

Worth noting that I've tried this with both alacritty and st and they seem to work the same. Both also work as expected with 3.4

@JBlocklove if you run printf '\033[>4;2m' before showkey -a, both inside and outside of tmux, what do you see?

@JBlocklove it is also possible that vim-tmux-navigator plugin needs to be updated for tmux 3.5. If you can hold on until a few days, we will take a look into how it all interacts now.

I see the same things in showkey -a both in and out of tmux, just ^H. It looks like that printf didn't do anything? It seems this is also true of tmux 3.4, which I hadn't checked with showkey earlier. I guess there might be something else going on with how the keys are interpreted that's causing this issue. Whoops, got my configs a bit turned around. With 3.4 when I have my config as I posted earlier I don't see anything in showkey, I assume because tmux is capturing those inputs first?

Yeah, I suppose it might be a vim-tmux-navigator issue. I'm fine using 3.4 for a while longer if things need to be ironed out with my plugins. Thanks for the help!

Worth noting that I've tried this with both alacritty and st and they seem to work the same. Both also work as expected with 3.4

@JBlocklove have you tried it in Kitty? Does it work there?

I managed to get Control+Shift+x work in tmux 3.5 in Alacritty.

In alacritty config toml file I have this:

[keyboard]
bindings = [

{ key = "x", mods = "Control|Shift", chars = "\u001b[120;6u" },
...
]

@JBlocklove have you tried it in Kitty? Does it work there?

I managed to get Control+Shift+x work in tmux 3.5 in Alacritty.

In alacritty config file I have this:

[keyboard]
bindings = [

{ key = "x", mods = "Control|Shift", chars = "\u001b[120;6u" },
...
]

Haven't tried Kitty for this. This issue isn't big enough for me to switch terminal emulators and I like alacritty.

I added this to my alacritty config and it doesn't seem to have changed anything with how it interacts.

[keyboard]
bindings = [
	{ key = "L", mods = "Control|Shift", chars = "\u001b[108;6u" },
	{ key = "H", mods = "Control|Shift", chars = "\u001b[104;6u" },
	{ key = "K", mods = "Control|Shift", chars = "\u001b[107;6u" },
	{ key = "J", mods = "Control|Shift", chars = "\u001b[106;6u" }
]

I tried it with both the unicode for uppercase and lowercase letters. The rebind works if I check in showkey -a outside of tmux, but in tmux it's back to ^H and the like.

Interestingly, adding those bindings seems to have broken it in tmux 3.4...

Haven't tried Kitty for this. This issue isn't big enough for me to switch terminal emulators and I like alacritty.

I mean for testing not switching.

[keyboard]
bindings = [
	{ key = "l", mods = "Control|Shift", ...

what about lower L?

Also does x from my example work for you?

I mean for testing not switching.

[keyboard]
bindings = [
	{ key = "l", mods = "Control|Shift", ...

what about lower L?

Also does x from my example work for you?

Fair. Just installed kitty and tried this, I get the same results as with alacritty and st.

Lowercase doesn't seem to fare any better.

I bound C-X to select-pane -U to test it with the line from your alacritty config and it doesn't seem to do anything for me. How do you have it bound in your tmux.conf?

in tmux conf I have:

bind -n C-S-x kill-pane

and it works in alacritty

Eyyyy, that does work! Looks like I just had to get the combination of changes right! My pane switching now works with the following in my configs:

alacritty.toml

[keyboard]
bindings = [
	{ key = "L", mods = "Control|Shift", chars = "\u001b[108;6u" },
	{ key = "H", mods = "Control|Shift", chars = "\u001b[104;6u" },
	{ key = "K", mods = "Control|Shift", chars = "\u001b[107;6u" },
	{ key = "J", mods = "Control|Shift", chars = "\u001b[106;6u" },
	{ key = "x", mods = "Control|Shift", chars = "\u001b[120;6u" },
]

tmux.conf

set -g @vim_navigator_mapping_left "C-S-h"
set -g @vim_navigator_mapping_right "C-S-l"
set -g @vim_navigator_mapping_up "C-S-k"
set -g @vim_navigator_mapping_down "C-S-j"

Thanks for all the help!

Annoying part is that you have to manually set those shortcuts in alacritty config while they should work out of the box :/