Code change:
I've seen this happen a few times now, and this last time it seemed to happen right after I closed a VS Code window. After that, I got the following notification in all my other open VS Code windows. ! Here is the Shared Process output
Going to look into whether we can wait for the process input to stop before actually killing the process for windows as another workaround for This process can take a bit of time now if needed since it's off the window being shutdown which has limited time to react.
It looks like we are using the same method as before where we indicate to dispose immediate. Perhaps it's different before because the window going down would more aggressively shut down its child processes?
we can consider bringing this in for the recovery build if we start seeing reports.
No, a few seconds after I open a second VSCode instance, this error message appears in both instances. It also happens if I open a second terminal in one instance
an extension may be closing the terminal, or it might be getting relaunched if an extension changes the environment (like the git extension will do when opening a new workspace). Does it happen if you open a new window and then wait 10 seconds before opening a terminal, such that extensions can activate?
I had the problem even with uninstalled extensions. But the good old "did you try turning it off an on again" helped. After a windows reboot, everything works fine
To clarify the scope of this fix since is still seeing lingering issues in insiders for this that we aren't able to nail down. Verified here means that the mechanism to delay killing the process on Windows for up to 5 seconds works as expected.
Don't know if this helps, but I've noticed that it consistently happens if I open a terminal in 2nd level (is that the vscode term for running vscode "inside" vscode?), after closing that 2nd level all terminals are stuck.
VSCode 1.55.0, the issue is still there. Single instance of VSCode looks fine, but starting another instance fires the warning almost immediately, breaking terminals in both instances.
It did not happened with git console but happens a lot with powershell but git has this other problem .
I've been getting this recently, though consistently throughout my day, while doing remote ssh sessions through the vscode terminal window. I open a new terminal and then use wsl2, and within wsl2 doing the ssh sessions. I experience this in both of the following VSCode versions: Version: 1.55.1 (user setup) Commit: Date: 2021-04-07T15:06:02.360Z Electron: 11.3.0 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0. Version: 1.56.0-insider (user setup) Commit: Date: 2021-04-09T09:50:06.816Z Electron: 11.4.2 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0.
for me, even single instanse of vscode show this message, if i want to restart "watch" task
Update:
Started getting this error in VSCode 1.55.2 after upgrading to Chrome OS v90; appears to cause the whole VM to seize. Persists after full powerwash & fresh VM/Code install, no exts enabled. :( UPDATE: FWIW, I have not experienced the issue on Chrome OS Version 90.0.4430.100 since updating to Code v1.56.0
I'm getting this error all the time since some months. If I start an npm script in VS Code this error occurs. So I had to switch to the git bash terminal (Windows). Hope this gets fixed... Still happens with 1.56.0
I am receiving this same error myself. I only have a few extensions installed and I've been extremely stable until I installed the PowerShell Extension. At that point I immediately receive the error that "The connection to the terminal's pty host process is unresponsive", as well as two others: "the language service could not be started", and "Loading the PowerShell extension is taking longer than expected. If you're using privilege enforcement software, this can affect start up performance" I'm pretty new to using VS and programming in general so I'm not sure what to do about this.
this should be fixed in the build as of today, coming to stable in a month or so.
Hey forgive me if this is a dumb question but the Insiders build is kind of like a "beta" build? So there's the potential for it to have issues in other areas? Just weighing the pros and cons of getting the extension working vs. potentially having issues in other areas.
yes it is, you may get some instability but also access to new fixes/features. But this issue is fixed (finally), it just won't be available in stable until early next month.
sounds like you have the accessibility mode on, click the "screen reader optimized" button in the status bar.
I get this all the time even in the Insiders build and with no extensions. It started for me right after updating to macOS Big Sur v11.4
this is the only know case where this can happen on macOS
I'm getting this issue all the time at Windows10 (so I guess it's not just related to macOS) I usually keep open plenty of VS code projects (usually 2-5 at the same time). TBH it just got so unbearable, I launch external terminals manually whenever it's possible. (So basically every time, except when I'm using a debugger) My system specs are Any feedback/fix suggestions are greatly appreciated
the new release which fixes this should be out next week.

Related discussion:
text: resolved "https://registry.yarnpkg.com/node-addon-api/-/node-addon-api-3.1.0.tgz#98b21931557466c6729e51cb77cd39c965f42239" integrity sha512-flmrDNB06LIl5lywUz7YlNGZH/5p0M7W28k8hzd9Lshtdh1wshD2Y+U4h9LD6KObOy1f+fEVdgprPrEymjM5uw== <del> node-pty@0.10.1: version "0.10.1" resolved "https://registry.yarnpkg.com/node-pty/-/node-pty-0.10.1.tgz#cd05d03a2710315ec40221232ec04186f6ac2c6d" integrity sha512-JTdtUS0Im/yRsWJSx7yiW9rtpfmxqxolrtnyKwPLI+6XqTAPW/O2MjS8FYL4I5TsMbH2lVgDb2VMjp+9LoQGNg== </del> <ins> node-pty@0.11.0-beta7: version "0.11.0-beta7" resolved "https://registry.yarnpkg.com/node-pty/-/node-pty-0.11.0-beta7.tgz#aed0888b5032d96c54d8473455e6adfae3bbebbe" integrity sha512-uApPGLglZRiHQcUMWakbZOrBo8HVWvhzIqNnrWvBGJOvc6m/S5lCdbbg93BURyJqHFmBS0GV+4hwiMNDuGRbSA== </ins> dependencies: nan "^2.14.0"