As per various other discussions I bound opt+<- to 0x1b 0x62and opt+-> to 0x1b 0x66. This works great in zsh, but not in tmux.

In tmux opt+<- does jump backwords per word, but also seems to do some mode modification… when typing s afterwards, the character under the cursor will be deleted.

I also have issues with cmd+-> (0x05) and cmd+<- (0x01) – in zsh those keys navigate to the end and the start of the line, but this doesn't work at all in tmux.

I don't think there are any keybindings for these hex codes, so I assume something gets lost on the way from iTerm2 to tmux… Calling read in zsh directly and in tmux outputs the same codes for the opt bindings mentioned above, but it doesn't output anything for the cmd bindings in tmux.


I experimented a little bit more and discovered that the bindings work fine when using /bin/bash in tmux and only break when using zsh in tmux. I even tested /bin/zsh without loading .zshrc to check if something is wrong with homebrews zsh, but the bindings are broken there too. It seems like this is actually an issue with zsh.


More experiments! This seems to be connected to the $TERM environment variable that is set to "screen-256color" by my .tmux.conf – this seems to be correct to get the colors working, but as soon as zsh runs with this environment variable, the navigation stops working. Running TERM=screen-256color zsh reproduces the issue.

  • Did you use bindkey -e after starting zsh with no .zshrc? Otherwise it doesn't work even in the regular terminal. – SilverWolf Sep 10 '17 at 22:45

Seems like I finally found an answer! Or rather a workaround, since I'm still not sure what exactly is going wrong.

Explicitly configuring the key binds for word navigation fixed the issue for me:

bindkey "^[f" forward-word
bindkey "^[b" backward-word

Maybe zsh is using different keybindings based on $TERM.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .