Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I try to switch panes in tmux with ctrl+b , tmux sporadically prints the corresponding character code [A, [B, [C, or [D instead of switch panes.

I can do this repeatedly, exactly the same way, 75% the time it will switch properly and the other 25% the time it will print the character code instead.

ctrl+b <up arrow>    prints [A
ctrl+b <down arrow>  prints [B
ctrl+b <right arrow> prints [C
ctrl+b <left arrow>  prints [D

I'm using cygwin connected to Linux Mint. Tmux is running on Linux mint, and the shell I'm using is bash.

Edit: to make this question more search-friendly, I'll add these keywords:

Terminal outputs character codes open bracket A, open bracket B, open bracket C, open bracket D.

Any ideas?

share|improve this question
What terminal emulator are you using under Cygwin? mintty? – jjlin Jan 22 '13 at 0:02
Terminal emulator is mintty with terminal type set to xterm-256color. – Matthew Jan 22 '13 at 18:07

It sounds like tmux’s escape-time is set a bit to low for the quality of connection you have between your Cygwin system and the Linux system.

Many terminals generate the three byte sequence ESC [ B for the down-arrow key. The escape-time setting tells tmux how long it should wait for a complete sequence after receiving the ESC; if time runs out without receiving a complete sequence, then tmux will treat the individual bytes as individual keystrokes (treating C-b ESC as an unbound tmux key, and passing [B to the active pane’s tty).

So, either you have escape-time set to a very low value (which probably works OK when you access tmux over strictly local connections), or the connection between the two machines sometimes ends up lagging just a bit longer than your escape-time value. You can query the current value with the command tmux show-options -s | grep escape-time.

The default is 500 milliseconds; this should work OK in most situations, but might be too short for marginal connections. You might try raising the value of escape-time:

set-option -s escape-time 1000

You can put this in your ~/.tmux.conf file, run it as a tmux command in a shell inside a tmux session, or type it directly at tmux prompt (opened with C-b :). Note: Changes made in ~/.tmux.conf will not take effect until you re-source the file, or restart your tmux server.

share|improve this answer
+1 for awesome explanation, unfortunately it did not fix the problem. The problem appears to be worse after increasing escape-time :( I should note that the arrow keys do act similarly strangely when attempting to navigate the tmux command line (ctrl+b :). Pressing left to move the cursor on a partially-completed tmux command sometimes erases characters instead of moving the cursor, and I need to press 'i' to be able to type again as if it has vi key bindings and escape was pressed. You're probably right about it being a slow connection problem, but higher escape-times makes it worse. – Matthew Jan 22 '13 at 19:31
Well, that behavior at your tmux command-line definitely sounds like a delayed escape sequence problem: the ESC takes you out of insert mode, the [ is ignored (it is not bound in the vi-edit table), and the D is the delete-end-of-line command. I would not have expected a high escape-time to worsen the interrupted-escape-sequence problem; though, it would make vi-style bindings inconvenient—you would always need to wait for escape-time to elapse after pressing the ESC key (i.e. to exit insert mode), and before starting to type normal-mode commands (e.g. b to move back a word). – Chris Johnsen Jan 22 '13 at 21:06
Why would this only happen under tmux and not at all when just in bash or a gnu screen session? – Matthew Jan 22 '13 at 22:07
Also, it only occurs when interpreted by tmux (after ctrl+b or while on tmux :command line); I can press the arrow keys repeatedly at the terminal in a tmux window with no problems (bash prompt in tmux session). – Matthew Jan 22 '13 at 22:24
Assume the terminal wants to send the three byte sequence ESC [ D, but it pauses after the first byte. If this occurs after your Prefix, the leading ESC is “eaten” as a bindable key combination (Prefix ESC). In vi-style command line editing mode it is “eaten” as the vi return-to-normal-mode key. When you are typing at a tty (e.g. bash in tmux), the ESC is never “eaten”, it it just sent on to the underlying tty as a “separate” key; if the listening process (bash) is not as picky about Escape vs. start-of-sequence, then it will simply wait for the [D and treat it as a left arrow. – Chris Johnsen Jan 23 '13 at 3:31

I'm having this problem as well; it's definitely specific to the arrow keys (and probably cygwin) For the time being I decided to just unbind the arrow keys and move the select-pane commands elsewhere, and the new key bindings work flawlessly. Not a very satisfying solution though. I'd love to hear if anyone figures out what is going on.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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