Adding `set t_u7=` to the top of my vimrc as a workaround fixes it.

Original comment by dbarn...@google.com on 2 Aug 2015 at 9:24

Oh, and it's a transient issue not consistently reproducible. I think it has 
something to do with my machine being slow and/or using vim over SSH, but it 
repros in xterm, gnome-term, etc.

Original comment by dbarn...@google.com on 2 Aug 2015 at 9:26

You could try this: in src/term.c, change the length checks to one less:

        if ((*T_CRV != NUL || *T_U7 != NUL)
            && ((tp[0] == ESC && len >= 2 && tp[1] == '[')
                || (tp[0] == CSI && len >= 1))
            && (VIM_ISDIGIT(*argp) || *argp == '>' || *argp == '?'))

Assuming that you only received ESC [ it would currently not check for a match, 
it needs another character.  Disadvantage: if you actually type ESC [ the same 
would happen...

Original comment by brammool...@gmail.com on 4 Aug 2015 at 12:04

FYI, I've been trying to repro so I can try the fix but haven't seen it happen 
recently. Vim hasn't updated so I don't think it's actually fixed itself. Still 
keeping an eye on it.

Original comment by dbarn...@google.com on 14 Aug 2015 at 5:31

I got it to repro again and changing the length checks like #3 above doesn't 
seem to have helped.

Original comment by dbarn...@google.com on 18 Aug 2015 at 1:36

Any progress on debugging this? Still seeing it on Vim 8.0.378 on Debian Testing with various terminals. Seems to be a race in the request for terminal version and the response.

Well, if you can reproduce it, you're the best person to debug it.
You could use the ch_log() functions to get a debug log with timestamps.
Using breakpoints is unlikely to help debugging this.

Check your vimrc for <Esc> remaps. If found, change them to happen on autocmd TermResponse *.

Worked for me, found here:
https://stackoverflow.com/questions/54370424/weird-behaviour-vim-starts-in-command-line-mode
https://stackoverflow.com/questions/11940801/mapping-esc-in-vimrc-causes-bizarre-arrow-behaviour

I can reproduce this consistently, with a small setup.
What I see (in a file with a single # on the first line) is:

  #1$r2 q^[\^[[?12;2$y

It is only a visual artifact, the buffer is not corrupted.

I created 2 script traces. broken.script and working.script. I will attach them.

If I run cat broken.script the window is left with :1$r2 q^[\^[[?12;2$y on the command line

I'm using:

VIM - Vi IMproved 8.1 (2018 May 18, compiled Aug 23 2019 11:45:44)
Included patches: 1-1912

with syntastic from git (through vundle):

commit 0336c35c0b10b46d85cdd9c3df721f978429e82c (HEAD -> master, origin/master, origin/HEAD)
Author: LCD 47 <lcd047@gmail.com>
Date:   Sat Jul 20 09:01:01 2019 +0300

and vundle:

commit b255382d6242d7ea3877bf059d2934125e0c4d95 (HEAD -> master, origin/master, origin/HEAD)
Merge: 9a38216 8d6cb1b
Author: Ryan L McIntyre <8083459+ryanoasis@users.noreply.github.com>
Date:   Fri Aug 16 21:29:41 2019 -0700

with .vimrc:
set nocompatible
filetype off
set rtp+=~/.vim/bundle/vundle/
call vundle#rc()
source ~/.vimrc.bundles
filetype on
set bg=dark

let g:syntastic_check_on_open = 1

.vimrc.bundles:

Plugin 'gmarik/vundle'
Plugin 'vim-syntastic/syntastic'

in an xterm
with TERM=xterm-256color

wwalker@polonium:~/.../src/dot-files/common (master * u= origin/master)$ xterm -version
XTerm(334)

Interestingly it doesn't happen in urxvt.
It doesn't happen if ```bg=dark```
It doesn't happen if ```let g:syntastic_check_on_open = 1``` isn't set

It is reproducible all the time.  Whether running vim locally, or ssh'd or in a tmux (local or remote).

Since I have finally found what is causing it, I wanted to document it for others.

let g:syntastic_check_on_open = 0

Works around it for me.

I can do any troubleshooting you would like.

Also, these are my xrdb things for xterm:

XTermVT100.cutToBeginningOfLine: True
xtermutf8: 2
ttyModes: erase ^?
XTermcursorBlink: True
XTerm.VT100.color4: CornflowerBlue
XTermfaceName: DejaVu Sans Mono for Powerline
XTermfaceSize: 12
XTermfaceSize1: 8
XTermfaceSize2: 10
XTermfaceSize3: 12
XTermfaceSize4: 14
XTermfaceSize5: 16
XTermfaceSize6: 18
XTermforeground: white
XTermbackground: black
XTermVT100geometry: 81x21
XTermPopOnBell: False
XTermloginShell: True
XTermscrollBar: True
XTermaltSendsEscape: True
XTermsaveLines: 10000
XTermhighlightSelection: true
XTerm*metaSendsEscape: True
VT100translations: #override \n
,: string("") \n
,: string("") \n
Ctrl=: larger-vt-font() \n
Ctrl-: smaller-vt-font()

working.script.txt
broken.script.txt

Have you tried the workaround mentioned above:
Adding set t_u7= to the top of my vimrc as a workaround fixes it.

The problem is usually caused by a shell command during startup.

You are correct. Don't see how I missed that.
Thank you.

Well, set t_u7= made the garbage disappear from the top line.
Now it, sometimes, show up on the status line:
"ES_health" 2L, 79C^[P1$r2 q^[\^[[?12;2$y

Ignore that. it isn't useful to anyone. I can't reproduce it with a simple test case