Change:
Type: <bBug</bterminal git bash Enter and you will get delay VS Code version: Code - Insiders 1.90.0-insider (, 2024-05-06T08:07:13.626Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ rust-bundle1.0.0 glance0.0.8 project-manager12.8.0 redmodscript-lang0.2.0 redmodtweak-lang0.1.0 lit-html1.11.1 glsl-literal1.0.6 vscode-markdownlint0.55.0 vscode-eslint2.4.4 composer-php-vscode1.45. intelli-php-vscode0.12. phptools-vscode1.45. profiler-php-vscode1.45. rust-syntax0.6.1 gitlens14.9.1 EditorConfig0.16.4 prettier-vscode10.4.0 auto-close-tag0.5.15 auto-rename-tag0.1.10 copilot1.186.856 copilot-chat0.16. todo-tree0.0.226 path-autocomplete1.25.0 redscript-syntax-highlighting0.0.3 auto-comment-blocks1.0.1 dotenv1.0.1 debugpy2024.6.0 python2024.6.0 vscode-pylance2024.4.1 remote-wsl0.88.2 hexeditor1.10.0 vscode-extension-auto-import1.4.3 indent-rainbow8.3.1 vscode-yaml1.14.0 rust-analyzer0.3.1950 crates0.6.6 shader1.1.5 vscode-styled-components1.7.8 vscode-stylelint1.4.0 vscode-mdx1.8.4 highlight-matching-tag0.11.0 vscode-import-cost3.3.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
does this reproduce if you disable shell integration, ?
If I uncheck Shell Integration, it works well after terminal restart.
I have more details in with what's going wrong. The issue was introduced by this PR where becomes extremely slow
I had the same issue and setting to does the trick.
When I just hit the enter key on a bash prompt it takes about 4 seconds for the prompt to return. I ran process monitor and noticed many many (maybe over a hundred) instances of being spawned to run the shellIntegration- script.
Any idea where this ticket is tracked? Every reference to the issue is closed marking duplicate.
Closing an unfixed issue that everyone have ? I don't get the point
I closed this accidentally, have reopened.
worked for me !
Hey guys I'm having the same issue. Running a single is taking over 15 seconds to complete the command. After disabling , bash looks way better
The problem seems to be related to The issue happens also if I start (outside VsCode) my bash thus (same as VsCode does for its terminal): Each time the prompt must be shown (eg, after simply pressing the Enter key) a delay of about two seconds happens. Most of the delay is caused, it seems, by the function In particular, commenting out the line 178 seems to alleviate good part (not all) of the delay. Edit: More specifically, the culprit seems to be If I change the line 109 from to (effectively forcing "the switch to the faster function"), the problem goes away. (BTW: the faster function seems to have a bug of its own, it produces an extra prompt!)
Process monitor screenshot shows it re-running this over and over 89 times when I press enter at the shell prompt "C:Program FilesGitbin..usrbin" --init-file "c:UsersarthuAppDataLocalProgramsMicrosoft VS Coderesourcesapp/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-" !
Disabling is another workaround that improves the delay for me.
Hello Guys, This setting worked for me.
This helped me, thanks!
will move you to the old backend stack which significantly reduces the functionality/capabilities of the terminal. shouldn't do anything. is the right workaround for now, expect a fix soon though
what caused so many bash invocations when shell integration is enabled?
we started reporting the bash prompt in order to better position shell integration markers and understand the prompt. Apparently printf is just extremely slow on git bash
I had this terminal slowdown problem, in git bash, and found setting fixed the problem - the terminal was back to being fast. However, after the last, or recent, insiders update, even with that setting set to , the terminal is slow again - and it's showing the icons, etc. like it is ignoring this setting: ! !
you probably just didn't restart the terminal. This is now fixed and will come in the next Insiders and likely 1.90.1
Actually, I had the shell integration disabled for the last several insiders updates, so it has been off for a while. Terminal windows have been created and closed many time since. For whatever reason, when launching VSCode and the terminal session was restored, this last time, the integration feature was ignoring the flag. I terminated the terminal and started another, and the integration went away again. So basically the integration flag was ignored when the terminal session was restored. I just did a quick test of quitting VSCode, with a terminal window open, then relaunching, and the integration was still disabled. Unsure what happened. Guessing, also, you type-o-ed the version? I am already running 1.91.0 insider !
what happened was the terminal was restored which re-creates the process after vscode starts with the original environment, args, etc. No the next insiders build on Monday and v1.90.1 (stable)
when will be the next minor update, not the insider build so this terminal slowness is resolved?
FWIW, I can also observe the prompt's slowness on Linux (bash 5.1.16(1)-release on Ubuntu 22.04.4 LTS) on the order of a half-second or so (still annoying but bearable). looks like a temporary workaround for Git Bash only; will we fix the underlying cause of the slowness?
I also observe this to be slow over linux using an ssh remote. It's much slower if I have a starship prompt enabled (4s) and around 1s if I have the default debian prompt.
I have this issue (Win 10, git bash). The suggested workaround of disabling shell integration then restarting terminals worked for me.
Also having this problem. Disable terminal integration worked for me too. (Win 11, Git bash).
I re-enabled terminal integration with the latest Insiders - ! and it the problem seems to have been fixed. For me at least.
Yes, it's been fixed in insider's already.
Perfect solution
When is the release date for the VSCode stable one?
no exact date, but probably later this week
, Turning off shell integration only sorta helped me out. It does return a result slightly faster, but it does not return the prompt back for 4 seconds or so, but only with python poetry workspaces/folders opened. This slowness goes away if I don't have a workspace/folder open, a non-poetry python one, a javascript one, etc. There's now a '(packagename-pythonversion)' at the top of my prompt when I open a python poetry folder and that seems to be taking forever to generate after each command. Definitely wasn't happening before my last update. This seems like a separate issue? Or is it related somehow? Happy to open a separate Issue if needed.
I don't know if this is the same as your issue but I've found that, if I already opened a terminal in a workspace before changing the setting, I had to kill the terminal for that workspace and open a new one so it would be initiated with the updated setting.
Yes. With the feature disabled, issue does not happen . But the feature will not work also . I can live without that feature but I like it. It makes my IDE look smarter. It's strange. I remember the feature was there earlier without any issue.
Was the fix included in 1.90.1? The shell integration is still too slow even after I updated to 1.90.1. It still takes over a second for all those bash commands to run every time press the enter key at the terminal. I have to keep it off to keep my Windows git bash terminal usable. It seems like it takes around a second and a half to get a new prompt with that setting on. Is this expected? I just updated to this version: Version: 1.90.1 (user setup) Commit: Date: 2024-06-11T21:01:24.262Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0.
it should be fixed yes, can you run and paste in the results?
$ for i in {1..10}; do time _vscreport_prompt; done real 0m0.236s user 0m0.045s sys 0m0.092s real 0m0.194s user 0m0.045s sys 0m0.076s real 0m0.210s user 0m0.030s sys 0m0.122s real 0m0.217s user 0m0.015s sys 0m0.152s real 0m0.216s user 0m0.061s sys 0m0.138s real 0m0.245s user 0m0.045s sys 0m0.123s real 0m0.202s user 0m0.015s sys 0m0.091s real 0m0.212s user 0m0.061s sys 0m0.091s real 0m0.230s user 0m0.000s sys 0m0.153s real 0m0.212s user 0m0.045s sys 0m0.108s
It seems like it's taking a long time to parse the prompt. My git bash prompt is user MINGW64 /c/path/to/dir (master), where the my /c/path/to/dir is a 29 character path. But sometimes it's a lot longer. Does a longer path make it slower? When I cd to a 135 character path, and try to time it it just prints 633;D;0: $ time vscreportprompt 633;D;0 $ vscreportprompt 633;D;0
those numbers aren't too bad, but regardless I think we need to rethink how we're doing this prompt reporting feature. I'm going to stick it behind a setting in so it's just disabled completely by default.
This is still unreasonably slow, IMO. If I'm running a shell with the extensions the shortest possible interval between two commands seems to be over 700ms on my machine: ! Running without the shell integration, it's closer to 250ms, and that may only be because that's how fast I can press the ⇧⏎⇧⏎ keys: ! Despite the improvement over 1.90.0, I still feel like I have to disable the shell integration. It's 2024. Having to wait a perceptible amount of time just for the terminal prompt to re-appear feels like a huge regression to 1980s computing. Is my floppy drive trying to seek to a specific sector?
v1.91 which I think is being released today includes the changes I mentioned in , disabling the prompt reporting stuff completely (for the stable build): !
I'm running 1.91.0 (insiders) and I still see a significant delay between prompts (on windows, using git-bash terminal). Turning the shell integration off speeds it up quite a bit.
it's only disabled in the stable build. Insiders keeps the slower code as it provided reliability improvements and the plan is to optimize it soon.
While v1.91 does seem to improve the delay, there's still a noticeable delay for me so I'll be sticking with the option disabled.

Discussion:
for (( i=0; i < "${#str}"; ++i )); do byte="${str:$i:1}" <del> # Escape backslashes, semi-colons specially, then special ASCII chars below space (0x20) </del> <ins> # Escape backslashes, semi-colons specially, then special ASCII chars below space (0x20). # This is done in an unwrapped loop instead of using printf as the latter is very slow. </ins> if [ "$byte" = "" ]; then token="" elif [ "$byte" = ";" ]; then token="x3b" <del> elif (( $(builtin printf '%d' "'$byte") < 31 )); then token=$(builtin printf 'x%02x' "'$byte") </del> <ins> elif [ "$byte" = $'x00' ]; then token="x00" elif [ "$byte" = $'x01' ]; then token="x01" elif [ "$byte" = $'x02' ]; then token="x02" elif [ "$byte" = $'x03' ]; then token="x03" elif [ "$byte" = $'x04' ]; then token="x04" elif [ "$byte" = $'x05' ]; then token="x05" elif [ "$byte" = $'x06' ]; then token="x06" elif [ "$byte" = $'x07' ]; then token="x07" elif [ "$byte" = $'x08' ]; then token="x08" elif [ "$byte" = $'x09' ]; then token="x09" elif [ "$byte" = $'x0a' ]; then token="x0a" elif [ "$byte" = $'x0b' ]; then token="x0b" elif [ "$byte" = $'x0c' ]; then token="x0c" elif [ "$byte" = $'x0d' ]; then token="x0d" elif [ "$byte" = $'x0e' ]; then token="x0e" elif [ "$byte" = $'x0f' ]; then token="x0f" elif [ "$byte" = $'x10' ]; then token="x10" elif [ "$byte" = $'x11' ]; then token="x11" elif [ "$byte" = $'x12' ]; then token="x12" elif [ "$byte" = $'x13' ]; then token="x13" elif [ "$byte" = $'x14' ]; then token="x14" elif [ "$byte" = $'x15' ]; then token="x15" elif [ "$byte" = $'x16' ]; then token="x16" elif [ "$byte" = $'x17' ]; then token="x17" elif [ "$byte" = $'x18' ]; then token="x18" elif [ "$byte" = $'x19' ]; then token="x19" elif [ "$byte" = $'x1a' ]; then token="x1a" elif [ "$byte" = $'x1b' ]; then token="x1b" elif [ "$byte" = $'x1c' ]; then token="x1c" elif [ "$byte" = $'x1d' ]; then token="x1d" elif [ "$byte" = $'x1e' ]; then token="x1e" elif [ "$byte" = $'x1f' ]; then token="x1f" </ins> else token="$byte" fi

builtin printf "e]633;P;ContinuationPrompt=$(echo "$PS2" | sed 's/x1b/x1b/g')a" __vsc_report_prompt() { <ins> # HACK: Git bash is too slow at reporting the prompt, so skip for now if [ "$__vsc_is_windows" = "1" ]; then return fi </ins> # Expand the original PS1 similarly to how bash would normally # See https://stackoverflow.com/a/37137981 for technique if ((BASH_VERSINFO[0] >= 5 || (BASH_VERSINFO[0] == 4 && BASH_VERSINFO[1] >= 4))); then