The editor.multiCursorModifier vscode setting is editor specific and does not change the terminal alt+click behaviour.

There currently is no option available to disable the alt+click behaviour.

I think we would be open to a PR that introduces such a config option (maybe call it disableAltClickCursorMove which defaults to false to retain backwards compatibility)?

Code pointers:

Strong upvote from my side for being able to disable that feature completely, as it is basically broken 😸.

On a side note: Those tons of nonsense output are cursor movement sequences, that the canonical mode of the TTY cannot handle and instead echoes them back to the user. This will happen for most programs, that are not specially prepared for cursor movement and do not run the TTY in raw mode (you can test it with a simple read in a bash script).

I wouldn't call it broken, but rather "unreliable by design" 😬. We are basically using the same technique that is used by Terminal.app, which btw. produces the exact same problem:

The problem with this functionality is that is assumes a specific operation mode across the TTY and the slave program, it only works correctly if the line editor of the TTY is switched off (non-canonical) and the slave program has its own terminal view representation which allows cursor movements. This is typically the case for editors, anything else is likely to fail (vast majority of programs).

Shells are awkward in that case - some use canonical mode (ash/dash), shells like bash or zsh operate in raw mode and would work for right/left cursor movements, but not up/down as the history is typically linked against up/down.

REPLs in general share that problem, most very simplistic REPLs use canonical mode and would fail as well, more advanced ones do the full raw mode/own view repr thing and again link their history against up/down.

Last but not least there are curses programs, that might do whatever they want with cursor key sequences.

To summarize this:
The cursor key functionality is not predetermined, it is solely dependent on the slave program, what to make of it. Furthermore there is no way to tell the terminal side that a program is using cursor keys for text cursor movements. If we want to preserve the Alt-Click feature in a reliable way, imho only chance is to come up with a terminal sequence, that allows to switch on/off that feature. Then a program can decide on its own, whether to make use of this terminal feature. But thats kinda redundant, because the mouse terminal API already is capable to do this (simply activate mouse support from your program, listen for Alt-Click and move the cursor within your program accordingly).

TL;DR:
This feature is a false promise (to make it blunt: should not exist at all). There is no way to get it working reliably (even the most advanced heuristic will keep failing as long the slave program does not announce the support in a certain way).

👍 to adding a setting to disable this, that's needed to fix microsoft/vscode#101136 too so VS Code can disable it when "editor.multiCursorModifier": "ctrlCmd" is used. I'm not sure it's worth a setting in VS Code to explicitly disable it even when editor.multiCursorModifier is the default I don't think alt click does anything, so users would either be pleasantly surprised to discover the feature or confused and not do it again.

FWIW I don't use alt+click so it doesn't impact me much, but I know some do and the idea came from established terminal(s).

And definitely agree it's "unreliable by design" 😄