Any updates on this? Having the exact same issue pretty consistently as well. Let me know if I can contribute to the troubleshooting process.

Any solution ? Still have this issue 😦

After almost 3 years and exactly 100 comments later, I believe this has finally been fixed in the latest builds:

OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22621 N/A Build 22621
Windows Terminal Version:  1.16.10262.0
WSL2 OS:                   Ubuntu 20.04.5 LTS (Focal Fossa)
WSL2 Kernel:               Linux x1ce2 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Tmux Version:              3.0a
Shell:                     fish, version 3.6.0

The new text rendering engine had to be enabled (I think):

Here it is in action:

Though I haven’t active in the comments, I’ve been following it closely as I encounter it daily in my workflow.

I’m happy to declare this issue now resolved and closed. 🖖🏽

I solve it by adding “experimental.rendering.forceFullRepaint”: true, to json setting file

I found a weird workaround that works for me.

1. opening tmux with a split in one Terminal tab. Here I see the rendering error.

2. open a new terminal tab and attach to the tmux session. Now the issue has miraculously disappeared

I am running into this issue also. It seems to happen when I start my React applications in a tmux split pane and the start up script would automatically open up the React application in Edge. Switching context back into Windows Terminal and I can see this issue. I can fix it simply by closing the terminal, reopening it and re-attaching the running tmux session.

Windows Terminal Version: 1.6.10571.0 Tmux: 3.0a

I’m having similar issues. Windows 10, WSL2 Windows Terminal 1.8.1032.0 Ubuntu 20.04 (fully updated 2021-05-19) tmux 3.0a

Starting tmux, running commands, clearing the screen (with clear) works fine until I create a split pane (ctrl+b+%).

At that point running clear will clear only parts of the screen. The prompt is not or only partially displayed. After closing the split pane the screen is properly refreshed again.

I’m using default tmux configuration (no ~/.tmux.conf).

If I ssh into a RHEL8 server first and run tmux (version 2.7) there the same problem occurs.

Note I often notice a similar problem when running vimdiff but I haven’t nailed down the exact steps to reproduce that reliably yet.

FWIW none of the above worked for me. What ended up doing the trick for me was setting

set -ag terminal-overrides ',*:cud1=\E[1B'

in my .tmux.conf

I’m sorry to say, but this bug was such a deal-breaker that it prodded me to investigate alternative terminal emulators for Windows (others have already mentioned PuTTY, of course). I found Alacritty and have since moved all of my WSL workflows over to it rather than Windows Terminal. I highly recommend it – it’s GPU-accelerated and very configurable with a single YAML config file – you can tweak arbitrary keybindings and even visual minutiae like how many pixels the window borders use, very nice if you have a tiling setup. And of course you can use your daily driver programs like tmux and vim without fear of corrupting the display and having to restart your terminal every 10 minutes lolol.

It’s been, what, like 2 years? Time to move on.

I have a fix for my issue - disable Windows Scrollback in Ubuntu Terminal - works fine now.

Now how do we reconcile what conhost thinks here with what tmux thinks? That’s the hard question.

I’ve been assuming this would all be resolved by the epic buffer rewrite from issue #8000. Right now we can’t handle characters or character combinations that occupy two positions in the buffer, but are only meant to occupy one cell on the screen (zero width joiners are probably one case, surrogate pairs that are meant to render as narrow-width glyphs would be another).

But I’ve been thinking, if the buffer rewrite isn’t going to happen anytime soon, we might be able to hack a quick fix by just not storing those kinds of characters in the first place. Basically if we receive a zero-width joiner, just drop it. Similarly for narrow-width surrogate pairs, we could store a single error glyph instead. It’s obviously not going to look right, but at least it won’t then break the whole layout of the page.

There may still be other problems that are causing tmux to break, but I think it would help immensely if we could rule out all the obvious buffer-related causes.

I’m facing similar issue with tmux. What I’ve noticed is that it starts to occur when I run some script via npm in other tab

It’s very irritating and blocks me from using terminal+tmux+vim. Actually, not only vim is affected, I’ve issues with tmux scroll as well, so I’m not suspecting it’s a vim issue. My assumption is that npm prints some special character that breaks all other things. Are there any logs I can gather to help troubleshoot this issue?

Npm packages used:

• create-react-app link
• storybook link

For example, try something like this:

printf 'x\ufe0e%.0s' {1..100}

You’ll see the output from the left pane goes straight across into the right pane

How did I not see this before? Maybe GH auto-collapsing bits of the thread? Dang that repro’s all the way back to conhost:

So that’s at least the root of the issue. Now how do we reconcile what conhost thinks here with what tmux thinks? That’s the hard question.

This bug occurs sometimes for me. Horizontal splits always work, vertical ones sometimes bomb.

As a temporary workaround I’ve found that detaching my tmux session, then reattaching to it, resolves the problem for me. Not my favorite, but at least it’s something so I can move past the bug.

Windows 10 v21H2 build: 19044.1415 Windows Feature Experience Pack: 120.2212.3920.0 Windows Terminal: 1.11.3471.0 WSL: Version 2, Ubuntu-18.04, Kernel v5.10.60.1

Windows 10 Pro Terminal version: 1.10.2714.0 Tmux: 2.8-3 Debian: 10.10 WSL2

Same issue, was gone for a few months and now returned possibly due to some update of something.

Edit: updating tot debian 11/tmux 3.1c didn’t help. The issue did reappear (on a fresh tmux session) upon running yarn start in a tmux pane for a create-react-app application.

I couldn’t get a consistent set of repro steps for this the last time I investigated this: #6987 (comment). I haven’t had a chance to try again since. If someone could find an exact set of “use these settings, this tmux config, run this, that another” to repro this consistently, that would be much appreciated.

@j4james provided this one liner that consistently breaks tmux on WSL for me

printf 'x\ufe0e%.0s' {1..100}

FWIW, we’re pretty confident that "experimental.rendering.forceFullRepaint": true shouldn’t actually fix this. It might coincidentally fix this, by forcing a reboot of the Terminal, and maybe makes it harder to get into this state. But presumably this is due to a desync between the ConPTY buffer and the Terminal one, and that’s not something forceFullRepaint would affect.

I have experience the same issue

the split screen function can only work in horizontal split, not vertical split.

Short summary: what I was describing can be a combination of WSL2 + Windows Terminal (version 1.5.10411.0). On a different machine, the same problem does not reproduce with a WSL1 distro. On the same machine, switching to Windows Terminal Preview from Microsoft Store should also fix the problem.

Here are more a few more detailed notes: (I was using Pengwin for WSL on all three machines listed below.)

Apologize for not including all the details. Here are the Windows specifications for the desktop machine where I took the screenshot. I was using Windows Terminal version 1.5.10411.0, downloaded directly from Microsoft Store. I am using WSL2 on this machine.

Edition	Windows 10 Pro
Version	20H2
Installed on	‎1/‎31/‎2021
OS build	19042.804
Experience	Windows Feature Experience Pack 120.2212.551.0

Also, with the same version of Windows Terminal from Microsoft Store, the problem is reproduced on a T480 laptop with Win 10 Pro Version 1909. (Well, Pengwin is installed as WSL2 here.)

However, on another Lenovo T480 laptop with the following specifications, the Windows Terminal from the Store should work without a problem.

Edition	Windows 10 Pro
Version	20H2
Installed on	‎2/‎12/‎2021
OS build	19042.804
Experience	Windows Feature Experience Pack 120.2212.551.0

Here is a screenshot from the 2nd T480 laptop with Win 10 Pro Version 20H2. It is clean as it should be. Note, this is Pengwin installed as WSL1.

Looks like the Windows Termianl Preview (version 1.6.10412.0) does not produce the Tmux problem, though. Glad to find another viable alternative emulator.

Huh. I could not get this to repro with a fresh ubuntu 20.04 and tmux 3.0a, UNTIL I tried installing fish:

I’m not sure if it’ll happen again, but I could repro this at least once, so there’s something.

EDIT: tmux-256color is certainly a weird termcap:

@j4james great! Hopefully that will sort it. Thanks James, looking forward to the next release then.

for whoever this helps, I had no luck with any version or even with alacritty, HOWEVER recently came across WezTerm https://wezfurlong.org/wezterm/install/windows.html and it has worked like a charm. Very easy to setup and configure, and no rendering issues.

While ~70% of the issues have been fixed by disabling scrollback - I continue to see problems and corruptions - more often on my large 30" monitor - and almost always when I do a vertical split of a window into two tmux panes - Horizontal splits are rarely a problem. I have a (horrible) workaround - which is to kill the tmux-server and restart it (resurrection plugin restores all my panes/scroll back - so not the end of the world). This is definitely a windows terminal issues - I used tmux for 2+ years on a linux system - never once saw a corruption - and I see it daily on windows terminal. What I find surprising is that surely there are a lot of people who (A) use WSL, (B) used tmux, © use windows terminal - so there must be a lot of people experiencing this problem every day - Unless splitting a window vertically is just an uncommon thing.?

Nice to see the issue i’m battling with wasn’t just me. I see a similar issue within neovim as well. I initially thought it was the terminal overrides in the tmux config.

Alacritty 0.10.1 on Windows 11

I am experiencing this issue in both windows terminal and alacritty.

Referencing an alacritty issue (https://github.com/alacritty/alacritty/issues/5483) as it says it might be a windows bug not alacritty/terminal

Here is what happens in Alacritty

• v0.10.1
• Windows 11
• WSL2 Ubuntu 20.04

https://user-images.githubusercontent.com/47204120/171546527-4565676b-f6fa-4dc8-af68-339ab919d0dc.mp4

NOTE: Weirdly enough, the render issue only happens in vertical tmux splits not horizontal (at least in my case)

Nope. We’ll make sure to update this thread when there is.

I couldn’t get a consistent set of repro steps for this the last time I investigated this: https://github.com/microsoft/terminal/issues/6987#issuecomment-676510163. I haven’t had a chance to try again since. If someone could find an exact set of “use these settings, this tmux config, run this, that another” to repro this consistently, that would be much appreciated.

I suspect it has something to do with wide/narrow characters like the ones commonly found in nerdfonts powerline setups, but a consistent repro without those should also be possible.

“experimental.rendering.forceFullRepaint”: true, Thanks! works for me, too.

I had the same issue for a year now until I set LANG=en_US.UTF8 using sudo update-locale LANG=en_US.UTF8 as well as export LANG=en_US.UTF8

I also have set -g default-terminal "xterm-256color" in my .tmux.conf and tmux aliased to alias tmux="TERM=xterm-256color tmux -2"

Windows 11 Build 22000.282 Windows Terminal: 1.102714.0 Tmux: tmux 3.0a OS: Ubuntu 20.04.3 LTS on Windows 10 x86_64

Edit: Nope it doesn’t work 😕

Windows 11 Windows Terminal 1.10.2383.0 Tmux: 3.0a Ubuntu: 20.04.3 LTS

Still having the issue 😦

Sadly without any solution, it is really difficult to develop with Microsoft Terminal and tmux. I am back to mintty/wsltty

This is still easy to break by using a unicode sequence that Windows Terminal doesn’t render with the correct width. For example, try something like this:

printf 'x\ufe0e%.0s' {1..100}

You’ll see the output from the left pane goes straight across into the right pane like this:

If you’re using a fancy prompt with emoji in (like the cloud in @G-Rath’s screenshot above), I suspect that might be the cause of your tmux rendering problems.

“Redraw entire screen when display updates” was causing me a lot of issues with Tmux, Vim and React-Scripts (the start command). Disabled and everything is fine now.

Windows 10 - Version 21H2 - OS Build 19044.2604 Terminal 1.16.10.261.0 Ubuntu - WSL 2 Tmux 3.0a NVIM v0.4.3

@jradam That was perfect, thanks. This looks to me like the same problem as #14690. The DISABLE_NEWLINE_AUTO_RETURN mode has been inadvertently reset, so a line feed forces a carriage return, and when tmux or vim try to move the cursor down a line, it’s also mistakenly moved to the leftmost column. This results in things being rendered in the wrong place, e.g. when hilighting the import on the second line, it gets redrawn too far to the left.

In your case I’m assuming the mode change was triggered by yarn rather than wslsys (this would be an internal API call, so it’s not something I can tell from the script log), but I’m hoping it will also be fixed by PR #14735.

I honestly don’t really think there’s anything in 1.16.3460 that would have fixed this… I’d be excited to find out that it was fixed by chance.

https://github.com/microsoft/terminal/compare/v1.15.3465.0...v1.16.3463.0

Maybe:

• #13321

okay 200 commits later and that looks like the only one that might affect this. But I’m pretty sure WSL wouldn’t be invoking a ReadConsoleOutput at any point. Weird. There are some changes in 1.17 that do more to mess with the buffer. Those changes I’d think would be more likely to improve this. That being said, the repro in https://github.com/microsoft/terminal/issues/6987#issuecomment-917256763 is still broken in 1.17, so 🤷

^ Can confirm I don’t have this issue anymore with the Preview version 1.16.3460.0, thanks @theanuragshukla!

If Anyone is still having this issue, try installing Windows Terminal Preview from the microsoft store. Hopefully this issue will be resolved in upcoming versions of Terminal.

I was also finding refuge in Alacritty (have been a very happy user of it on Linux and MacOS for years) but in Windows Alacritty still has problems dealing with the system clipboard and NeoVim mouse events (https://github.com/alacritty/alacritty/issues/1663). These days to mitigate the bug in question I just have to run my Nodejs servers in a separate WT tab without Tmux.

I don’t feel that a “great” terminal emulator should have this problem, but I have to use it this way at work and consider it just another Windows UX hazard that breaks the Unix immersion of using WSL interactively.

@ghshephard Do you have more information on how to disable the setting you mentioned?

I am running into this issue also. It seems to happen when I start my React applications in a tmux split pane and the start up script would automatically open up the React application in Edge. Switching context back into Windows Terminal and I can see this issue. I can fix it simply by closing the terminal, reopening it and re-attaching the running tmux session.

Windows Terminal Version: 1.6.10571.0 Tmux: 3.0a

This happens here as well. WSL 2, Ubuntu22.04, Windows Terminal Version: 1.13.11431.0. Tmux 3.2A. Closing the terminal window or detaching from tmux resolves the issue.something seems to be happening when firefox is launched for the CRA dev server.

Launching firefox directly from the Ubuntu shell does not cause the issue.

Setting the CRA start script to "start": "BROWSER=none react-scripts start prevents the browser from auto-launching, and prevents the issue.

I think that @zadjii-msft is right that at least in some cases this is caused by advanced prompt setups with things such as powerline.

I did some testing today and was unable to reproduce the issue for myself if I set my shell to bash with no customization, but with my normal zsh + loads of nonsense, it is essentially unusable with a vertical split.

I am using zsh with Oh My ZSH!

My guess is that if you just set up the minimal Oh My ZSH! setup, it will replicate the issue.

Let me know if there is anything I can do to help move this along in the way of testing or providing examples of how to reproduce it.

Want to report that even with neovim split, still produced the same kind of display artifacts

Still having rendering issues using tmux with nvim on Windows Terminal Preview 1.7.572.0 I generally use tmux to split panes A temporary work around for my issue was to use Windows Terminal’s built in split panes I remapped most of the command shortcuts to be similar to tmux’s with the help of this https://docs.microsoft.com/en-us/windows/terminal/panes

I had this same issue on the official Windows Terminal, but it is seemingly fixed in the current Windows Terminal Preview v1.7.572.0.

Nope, still a problem for me with that version.

I now attribute the "new variant " of rendering error to vim-prosession, a Vim-plugin. To be more specific, I was including an E0056 character when I ask vim-prosession to update the window name when I enter vim from the command line. The following settings in .vimrc shall reproduce the problem.

let g:prosession_tmux_title = 1
let g:prosession_tmux_title_format = "V󠁖-@@@"

Note, on the 2nd line, there was an E0056 char between V and -. Inspecting the string "V󠁖-@@@" here shall reveal E0056.

For a good number of months, though, the E0056 char has been rendered properly with wsltty. Looks like Windows Terminal (or Preview) cannot handle the E0056 char properly when it is inserted into the status bar for Tmux.

I am having a slightly different problem, where the status bar for tmux should grow “taller” by duplicating itself. It also inserts a line with b-21 or 21 at the bottom. Tmux shortcuts are not working as intended as well. This is observed both on tmux sessions running in a local WSL instance, or tmux sessions hosted on remote Linux machines. The .tmux.config file for both tmux sessions are identical, as I source from the same Dropbox directory.

To note, all these problems go away should I stay with wsltty.

Alright other findings here

• Once a Windows Terminal pane is corrupted by this, it will stay corrupted. With the pane that’s busted for me, every time I try killing all my tmux sessions and opening a new one in that WT pane, it’s got the same visual corruption as OP.
• The corruption seems to be caused by tmux or conpty causing the mouse to go back to the 1st column instead of where the pane separator should be. maybe there’s a bug with calculating where the tab stops should be?
  • tmux is redrawing the contents of the bottom right pane correctly, but when I force a redraw of the entire window, then tmux will draw the corrupted rows starting from column 0, instead of the separator.