Change:
Issue Type: <bBug</bAfter updating to latest VSCode stable (1.59) I started encountering an error when running tasks (The connection to the terminal's pty host process is unresponsive, the terminals may stop working.). This used to work fine on 1.58.2 and I confirmed that it is broken on latest insider build too (1.60.0) I have a bunch of VSCode tasks for 'orchestrating' local docker setup, so I can run some commands to run builds and generate TypeScript clients directly from the UI. When I run tasks without any "dependsOn" tasks they run fine. If one task depends on single other task, it also runs fine. I have problems when single task have multiple entries in "dependsOn" section - it usually works fine for the first time after I open VSCode but then the issue happens and I have to fully restart VSCode to make it work again. VS Code version: Code - Insiders 1.60.0-insider (, 2021-08-06T06:41:50.275Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (1)</summaryExtensionVersion ------ csharp1.23.14 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --<details<summaryTasks hierarchy</summary</details
Every time I wake my mac up from sleep (since the latest update to ) I get this too: ! A lot of times all the terminal processes are still running too, so I have to open Activity Monitor to force close them.
! restart vs code ...
Duplicate of ,
that issue should be fixed already.
I got this earlier all the time and then I deleted everything and now I get it when I try to download python extension back. Tried older versions of both python and vscode and vscode insiders but cant find a fix.
I confirm this error "The connection to the terminal's pty host process is unresponsive, the terminals may stop working." since I've updated my Windows 7 installation to latest version. I used to have a very old Windows 7 x64 from 2014 without any updates installed - all versions of VSCode up to 1.67 were running with absolutely no problems related to the terminal. Then, after I updated Windows 7 to latest available as of June 2022, the same VSCode I had installed started to throw this error, with the terminal (Command Prompt / CMD) disconnecting frequently (perhaps every 10-20 minutes or so). I've even disabled the ConPTY to fall back to Winpty, but the exact same issue occurs, it doesn't help at all. I hope this report helps the devs in finding out the underlying cause of the error and perhaps a fix....
I'm trying to find a solution to this annoying issue. Can you point me in the right direction, please?
I have the exact same issue with the latest VSCode 1.68. Is there something I can tryor do? Could you point me in the right direction so we can solve this?
you should update windows, Windows 7 was EOL in 2020 ,ended%20on%20January%2014%2C%. Also you never got to use conpty as it's only in the later versions of Windows 10.
I'm still getting this error, but since last Friday June 24th (I'm using Insiders) the terminal recovers after about 1-2 minutes, which is very interesting. I'm not sure what has changed (for the better!), but after about a minute the connection to the terminal is restored automatically and I can continue working in it, without losing any previous information. Before June 24 the terminal never recovered or restored connection and I had to kill it and open another instance and start all over again. The restored connection notification is being logged to the devtools console as so I get a series of the following connection lost/restored cycles: Is there some kind of timeout involved here? I've read about a 10 second timeout, but I'm not sure where I can access and hopefully increase the value of? I've noticed this error occurs mostly if the terminal and/or VSCode itself is not being focused on for several minutes and I think it may be related to the occlusion tracker kicking in (just a thought). I would very much appreciate if you could provide any insight into increasing the timeout (if there's any possibility for that, of course). I'm willing to experiment, that's not an issue. Thanks a lot for your work!
Here are the timeouts related to the pty host heartbeat/responsiveness: You cannot customize them currently, if there's no communication between the 2 processes in 10+ seconds then there is something very wrong, allowing configuration here wouldn't be a great workaround.
That's interesting! Any reason why there's no communication between the app and the terminal processes for more than 10 seconds when VSCode is not focused on? In the latest Insiders from today I've noticed that the connection loss ONLY occurs if I'm not focused on/working in VSCode. So if I work in another program (let's say Postman or a browser) and have VSCode open on my other screen with its terminal open with a app running in it, it will lose connection after a while (it takes quite a while, maybe 10-20 minutes). Is there any chance to debug/fix this? The possibility of customizing the pty host heartbeat parameters (even if hidden, for dev purposes only) would certainly help! I have a feeling that waiting just a bit more (i.e. 12-15 instead of 10 seconds) before notifying would maintain the connection without issues for long periods of time, even if VSCode is not actively being focused on. Alternatively, do you know of any other, more general setting in VSCode (perhaps Electron-related) that would turn off the delay in inter-process communication? I recon there must be some kind of delay or slumber mode kicking in when the window gets un-focused. I'm thinking of something like starting VSCode with the native occlusion flag disabled, i.e. . Is there anything similar that we can use in this case for debugging? Even a temporary access to the value you mentioned, in the next Insiders release, would be valuable. Thanks again! Edit: I see there's another parameter described as It looks like the reconnect is always happening within this GraceTime period of 60 seconds, so I never lose access to the terminal completely. It means the 10 second timeout is a bit low, at least in my case. Problem is, it can get quite difficult to work while this error/disconnect pops up every 10-20 minutes.
I've been investigating by increasing the value above 5000 in . So instead of 5s I've tried 10s, 15s with various improvements in the frequency of terminal disconnections. Do you think this is a proper way of testing? I'm not sure how to go about otherwise...
This is unbelievably frustrating... After a clean install of latest Insiders the warning pops up without even starting the terminal in the first place! I have no extensions installed, nothing. It's clean as possible. What is going on? Anyone else struggling with this?
Having this same issue in macOS as of today. Per recommendation on , I set , but am still having this issue. It's persisted through a complete wipe of settings and a fresh install.
Thanks for your patience it's hard for us to investigate this kind of issue when we cannot reproduce it. Did you start seeing it after a specific version of VS Code? You could try reverting to an older one
I understand, not a problem. Right now I'm on 1.69.2, just upgraded from a 1.5x.x release a few days ago (1.57.x, I think). I was experiencing it then, which is why I upgraded. My issue with knowing what version I'm using is that I'm in an Enterprise environment and upgrades are centrally managed, so I don't usually upgrade myself unless I'm experiencing a specific issue, such as this. AFAIK I'm the only one in our environment who is experiencing this issue right now, so I'm checking to see what version others are using and may downgrade, if appropriate.
- In my case, this appears to be an unrelated issue, which causes the same symptoms in VSCode. Our Service Desk fixed another issue for me this morning, which caused general slowness, and this issue appears to be resolved as well.
! ! !
For MacOS folks that get referred here fixed the issue for me.
I've just tested it and does NOT fix the issue for me. Still getting in the terminal: and then the notification pops up:
Actually I'll amend my (MacOS) comment: changing the settings seemed to improve things but the issue has come back. While this is causing problems, is there a way to completely disable the integrated terminal or the pty host process? Or is this a feature request in Things I tried: Also set per Tried to "disable" the terminal following instructions in so now Terminal does not show up along side the Debug Console, Output, etc. panels. This may just have changed the panel UIs, though.
What has been suggested here does not work. I have this problem every time I try to install any extension. OS: Windows 10 21H2 VS Code Version: 1.70.2 (user setup)
Update: Upgrading my mac OS to Monterey solved the issue. I have no idea why. Any thoughts whether this is possible ? If I have VS Code open I have to restart the ptyhost process about every 15 minutes or so even if I've never opened the integrated terminal so just trying to think about possible options . Are there any logs I should share?
Has anyone managed to come up with a solution to this issue? I'm still seeing the dreaded pty host process becoming unresponsive banner every 5 minutes with the latest 1.73 and 1.74 Insiders.
no, even after upgrade windows and vscode to the latest version, the problem still persists. In fact, is so annoying that forces me to migrate to other Text Editor.
My guess is that this is the issue; for some reason the shared process isn't triggering the interval here when the window is not focused: Perhaps your system has some aggressive power options that prevent non-focused apps from consuming CPU? And/or it's killing "inactive" processes like the pty host? You could try reproduce this in Code - OSS and then try figure out exactly why the pty host process or its communication channel is going down. I can't reproduce this problem on my end unfortunately. No you cannot disable the terminal completely, the pty host process will try remaim even if you never launch a terminal. So hiding the panel is just a UI change, it doesn't impact the pty host.
Thanks for responding and trying to find the cause to this issue. There is something important that I would like to add to this discussion and which has probably everything to do with what some of us observe regarding the terminal's pty host process becoming unresponsive: This problem only started occurring after I upgraded my OS to the latest security updates a few months ago. As you probably remember, I had a Windows 7 x64 without any updates applied for a long time (years) - everything was working perfectly - VSCode up to about 1.65 was working flawlessly, I have never encountered this error until the faithful day I have installed all Windows 7 updates offered in with the latest Windows Update (which were last updated at the beginning of 2020, but at that point there were many updates installed, approximately 70). Since then I've started getting this dreaded error. Whatever I have tried and believe me, I did, does not solve the problem. The funny part is that certain people using Windows 10 and Linux are experiencing the exact same annoying problem. I'm wondering whether they have applied some updates which broke their OS and/or VSCode in some unexpected ways (case in point: aggressive power options you've mentioned above). However, I'm leaning toward other causes, such as encryption upgrades or something along those lines (side-channel related vulnerability fixes on both Intel and AMD CPUs)...
the original report looks like Windows 10 so it might just be coincidence that you started seeing it then. Also FYI vscode doesn't actually support Windows 7 anymore and it's also past end of life, meaning it doesn't get security fixes anymore (with some versions ending in Jan 2023).
No, not a coincidence. I have reverted to several VSCode versions used without any issues prior to the Windows update (those I used in 2020-2021 such as 1.50-1.60) and those also started throwing this "terminal's pty host process unresponsive" error on the updated Windows. I have tested at least a dozen older VSCode versions on the updated Windows and all of them are now exhibiting this behavior. So it seems like a Windows update has definitely produced some kind of regression along the update process. I'm suggesting that this exact same thing happens for other users on Windows 10 or Linux as well - they update and then all of a sudden the terminal becomes unresponsive. I will have to try performing a clean Win 7 install, update it to latest available and only then install VSCode and see...
same thing here.. this problem started after some windows updates few weeks ago, before the updates vs code worked perfectly I've tried all the solutions i could find online (, remove all .vscode/ .vscode-server files from my pc and from the server and reinstalling, using insiders etc.) but it keeps happening, I have to restart the terminal every 10 min, making it impossible to work OS: Windows 10 Pro VS Code Version: 1.73.1 Remote server: Linux 4.15.0 Ubuntu SMP i really hope you'll figure it out soon so i won't have to switch to other editor
Having the same issue: OS: Windows 10 Hone VS Code Version: 1.73.1
I've discovered that this issue is in fact caused by crashing on our systems after performing an OS update. For me the issue usually occurs while running a webpack-dev-server with hot reloading - it is in fact first throwing the following error in the terminal: and then, a few seconds later, VSCode pops up the notification . I have tried running the dev server in a Command Prompt outside VSCode and it also crashes every 5-10 minutes, the same way it crashes in the VSCode's terminal. So this is itself crashing, whether it's the globally installed Node or VSCode's Node. So basically I assume the Windows Update somehow broke the currently installed Node, or at the very least made it very unstable. I confirm this occurs on Windows 7 and 10, with the globally installed Node 12 and also with Node 16. Reinstalling doesn't solve the issue. Any ideas what can be done?
Thank you very much, now, this was a pretty good piece of information! I've downloaded the last VSCode release then, remove all Node instances from my system and the problem stopped! And, to solve de Node issue I've downloaded the .zip with the binaries and configure the Path for my local user only. This seams to have solved the problem for me, vscode is running good now! I'll post if anything new appears!
Well, that's interesting! Can you please give more details on the exact versions you are using and how you set up the system, also what OS are you using, etc? I'd like to try your solution.
Would you please respond? Others might find your insights helpful... This is a long-standing issue which I haven't seen a clear solution for (yet). So detailing it would really mean a lot for some VSCode users, I bet.
Hi, actually (and unfortunately), it was fake news… One day after and the problem persist. However, I’m still trying to figure it out how it holds steady for 5 to 6 hours though! My actual setup is: Windows 10 v.10.0..2251; VSCode (x64) v.1.74.0 (I’ve downloaded the .zip file, not the installer); NodeJS (x64) v.18.12.1 (once again, .zip, only local install); And I'm using Git Bash as my default terminal profile; !
Thanks! I actually have noticed some improvement as well (terminal stays alive for about 30 min instead of 5-10 min), but only if I start my npm scripts from the VSCode Explorer. It seems it restarts the npm script(s) automatically after it crashes. I have tested this in both VSCode 1.74.1 and latest Insiders 1.75. I will soon do a clean Windows install and try again - I really hope it's not a hardware (or some driver)-related issue.
Note: this error pops up much less often in VSCode Insiders, so more like every 30 mins, instead of every 5 mins in regular VSCode. Might have something to do with Insiders being sandboxed...
I'm having a similar issue, but only on the most recent VSCode Insiders. It's the same "pty host process is becoming unresponsive" message, but it doesn't happen locally at all. It only happens when I'm using a remote dev container through the Remote-SSH and Dev Containers extensions. I turned off all the other extensions and it still happens immediately every time I try to start the dev container (even a default Alpine dev container with no additional configurations) and immediately after clicking the restart button. I'm connecting from Windows to a Linux server. I installed the most recent stable VSCode version and it worked instantly without any fuss or other changes. VSCode Insiders versions: Version: 1.75.0-insider (user setup) Commit: Date: 2023-01-31T00:03:50.170Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: WindowsNT x64 10.0. Sandboxed: Yes VSCode versions: Version: 1.74.3 (user setup) Commit: Date: 2023-01-09T16:59:02.252Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No
This error is most probably caused by the Electron bug
Similar issue to , when using v1.75.0, which is a part of the January 2023 release. under the tab shows: . Upgraded to the latest release using under the menu and could not use my terminal within VSCode: Version: 1.75.0 (user setup) Commit: Date: 2023-02-01T15:23:45.584Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No Downgraded to and able to use my terminal within VSCode again: Version: 1.74.3 (user setup) Commit: Date: 2023-01-09T16:59:02.252Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No ** You might also need to disable auto-updates. I don't remember setting the option for auto-updates but it requires manually disabling it after using . I went to settings, searched , change to . To apply will require a restart which caused it to install the update for me again. I just ran the installer again and good to go.
Had this same problem after an update to 1.75 last night, rolled back to 1.74.3 as suggested and it all worked again. My system is a Fedora 34 VM.
I updated to v1.75 and now get the error "the connection to the terminal's pty host process is unresponsive, the terminals may stop working." I tried downgrading to v1.74/v1.73 and downgraded PowerShell Extension as well, but issues still persists. ! ! PowerShell x64 5.1 and 7.2 have the error, but x86 5.1 does not. Version: 1.75.0 (user setup) Commit: Date: 2023-02-01T15:23:45.584Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No
Commit: Date: 2023-02-01T15:29:17.766Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: Linux x64 6.0.12-100.fc35.x86_64 Sandboxed: No 2023-02-09 09:18:26.889 [info] Extension host agent started. 2023-02-09 09:22:31.318 [info] Got delay-shutdown request while in shutdown timeout, delaying 2023-02-09 09:22:31.318 [info] Cancelling previous shutdown timeout 2023-02-09 09:22:31.474 [info] [127.0.0.1][][ManagementConnection] New connection established. 2023-02-09 09:22:31.477 [info] [127.0.0.1][][ExtensionHostConnection] New connection established. 2023-02-09 09:22:31.483 [info] [127.0.0.1][][ExtensionHostConnection] <210Launched Extension Host Process. 2023-02-09 09:22:56.028 [info] Got delay-shutdown request while in shutdown timeout, delaying 2023-02-09 09:22:56.029 [info] Cancelling previous shutdown timeout 2023-02-09 09:23:27.785 [info] [127.0.0.1][][ManagementConnection] The client has reconnected. 2023-02-09 09:23:30.421 [info] [127.0.0.1][][ExtensionHostConnection] The client has reconnected. 2023-02-09 09:23:33.186 [warning] No ptyHost heartbeat after 6 seconds 2023-02-09 09:23:38.187 [error] No ptyHost heartbeat after 12 seconds 2023-02-09 09:24:21.345 [warning] No ptyHost heartbeat after 6 seconds 2023-02-09 09:24:26.346 [error] No ptyHost heartbeat after 12 seconds 2023-02-09 09:25:24.105 [warning] No ptyHost heartbeat after 6 seconds 2023-02-09 09:25:29.106 [error] No ptyHost heartbeat after 12 seconds 2023-02-09 09:27:56.030 [info] New EH opened, aborting shutdown 2023-02-09 09:29:51.187 [error] No ptyHost response to createProcess after 5 seconds 2023-02-09 09:30:20.650 [info] [127.0.0.1][][ManagementConnection] The client has disconnected gracefully, so the connection will be disposed. 2023-02-09 09:30:20.781 [info] [127.0.0.1][][ExtensionHostConnection] <210Extension Host Process exited with code: 0, signal: null. 2023-02-09 09:30:20.781 [info] Last EH closed, waiting before shutting down 2023-02-09 09:30:26.359 [info] Got delay-shutdown request while in shutdown timeout, delaying 2023-02-09 09:30:26.359 [info] Cancelling previous shutdown timeout 2023-02-09 09:30:26.532 [info] [127.0.0.1][][ManagementConnection] New connection established. 2023-02-09 09:30:26.541 [info] [127.0.0.1][][ExtensionHostConnection] New connection established. 2023-02-09 09:30:26.549 [info] [127.0.0.1][][ExtensionHostConnection] <2544Launched Extension Host Process. 2023-02-09 09:30:32.187 [error] Error: disposed at p.k () at () at at p.invoke () at v.deliver () at u.fire () at I.setLogLevel () at w.call () at s () at s.q () at at p.invoke () at v.deliver () at u.fire () at A.fire () at s.E () at at p.invoke () at v.deliver () at u.fire () at h.acceptChunk () at at p.invoke () at v.deliver () at u.fire () at u.t () 2023-02-09 09:30:32.189 [error] Error: disposed at p.k () at () at at p.invoke () at v.deliver () at u.fire () at I.setLogLevel () at w.call () at s () at s.q () at at p.invoke () at v.deliver () at u.fire () at A.fire () at s.E () at at p.invoke () at v.deliver () at u.fire () at h.acceptChunk () at at p.invoke () at v.deliver () at u.fire () at u.t () 2023-02-09 09:31:19.009 [error] No ptyHost response to createProcess after 5 seconds 2023-02-09 09:32:00.182 [warning] No ptyHost heartbeat after 6 seconds
I just upgraded to 1.75.0 and started seeing this on all of my dev containers configurations. In a local window the terminal works fine. Related:
This issue makes VS Code unusable if you're using dev containers, after the latest update! Edit: A downgrade to v1.74.3 fixed the issue for the moment, to Downgrade on Fedora: .
This is a pretty breaking change making vscode literally unusable for all my use cases unless downgrading to 1.74.3 and disabling auto updates. All I do is remote dev containers.
Unable to use with all my privileged containers but able to use with non privileged ones. Even then I cannot use 1.75.0 because my work requires containers to be privileged. If need some logs, let me know
I am unable to connect to terminals in any remote docker host as well (both privileged and non-privileged).
For users starting to face this issue on containers starting with update, please follow The regression with is from an update to our terminal dependency that switched to use posix_spawn over fork to create terminal agents. This issue tracks a bug that was before the update and unrelated.
I wouldn't like to be proven wrong, but it seems this issue has been fixed in Insiders 1.77 from Thursday, March 9. I'm trying to track down the change that fixed it, the problem is I haven't used Insiders for about a week prior, so it's a bit difficult. So maybe one of these commits did the trick... The regular VSCode 1.76.1 is still throwing this error every 10 minutes , even though it was released March 9, AFTER the fixed Insiders version. So what gives?
I guess I spoke too soon. With the latest Insiders from Monday, March 13 the popup doesn't occur, but I have just noticed the error in devtools as follows: !
Got this recently, onto current version: 1.78.2 Mostly occurred when I'm trying to run a shell command, or use "Switch to Local branch and fast-forward" option from "Source Control" menu.
Still having this issue in 1.78.2 when running a script that takes over 5-6 minutes to complete.
I get a very similar symptoms on Win 10 with SSH started in integrated terminal for the purposes of tunneling xdebug connection back to client. The debugging will lock up until I open terminal and hit any key to wake it up. Then tunnel springs back to live and I could debug like normal. Very, VERY rarely, local shell terminal will lock up similarly.
I've got a thought. Could it be because the thread responsible for controlling the terminal goes to sleep in background, thus locking entire terminal?
I just received the update to 1.79.1. I was not receiving this message prior to that, but now I receive it every time I open a folder (context -"Open with Code"). That said, the terminal usually recovers in a few seconds. If I launch Code on its own and open a terminal, I do not receive the error.
The current theory is since this moved from the shared process to the main process, you're hitting a case where the main process is locked up with some other task (which is bad, but shouldn't break terminals). If that's the case, since we now have a direct communication channel from the window to the pty host (instead of going via shared/main proc), we can just monitor the stability of that.
Same issue here. On three different Windows 10 systems I get the error message on 1.79.1 whenever I start the editor. Downgrading to version 1.78.2 solves the problem.
I have confirmed several times that cache buildup causes all kinds of weird issues, such as the ones some users report here. I've found that doing a clean re-install fixes the problem. I'm missing some kind of "clear cache" button in VSCode which I think many people would need to use once in a while (every 3 months or so). Can it be done?
there are cached files in the user data dir which is where the settings file is , I really doubt cached files would impact main process/ptyhost process responsiveness though. Deleting the cache would also reset a bunch of stuff, for example you'd get a bunch of welcome notifications for various things/extensions.
If someone who can reproduce this now could check the pty host dropdown in the output panel that would be helpful. Specifically I'm interested in which one of these errors shows up:
In v1.78.2 (where I don't get the error) the "Pty Host" dropdown is empty. In v1.79.1 (where I always get the error) I don't even have a "Pty Host" dropdown in the output panel. Here are the messages in the "Main" dropdown in the output panel, if that's of any help: in the "Window" dropdown, eventually, this pops up: However, I still don't see a pty host entry in the dropdown list, sorry.
that's very useful, thanks!
So is this causing the issue? The ptyHost heartbeat stops right after the warning.
no. My current theory is we're starting the heartbeat tracker before we actually launch the pty host process since it now launched after LifecyclePhase.Restored. Need to do some testing to verify that
I can reproduce by changing these two lines in a : Meaning, if the pty host process takes an excessive amount of time to start for some reason (slow machine, anti-virus blocking it) then this will reproduce.
FYI: I timed the delay on two different systems. From the time the error window ("The unresponsive...") appears, it takes about 16.5 seconds until it disappears again and the PTY Host starts running normally. Maybe we can add a parameter that allows tweaking the time-out period? Waiting a few seconds longer for the terminal to show up is not a big deal; the error message is more annoying.
I had this issue for a long time on my previous machine (dual core only), so it makes sense that a slow machine can cause these timeout problems. I have switched to my desktop for the last couple of months and the problem is completely gone since. It's a quad core with clean Windows install. I would have to do an experiment: clean install Windows on the old dual core laptop and see if the issue still occurs there.
the thought also come up today that maybe it should be a status bar item when the terminal is focused, instead of a notification. Maybe only going to notification in the extreme case where it needs a restart or fails successive restarts. That way it would be a yellow status bar item that shows and goes away briefly, instead of an annoying notification.
I solved it with your downgrade method, thank you!
I've closed this out with the following changes: We now wait 20 seconds before the first heartbeat (26 seconds before notification) The pty host responsiveness alert is moving to the status bar to be less intrusive Better logs and debug settings to help spot and diagnose these sorts of issues I also spotted a few other issues with slow pty hosts which I'll look into if time allows this release: , , Note that this is actioning the most recent issue, not longer standing problems. This issue has been a bit of a dumping ground for all the problems so it's probably best to hit the reset button and create a new issue if there are remaining issues after all the changes that have gone in recently.
Thank you for the work you've done here! Hopefully this fixes the long-standing issues we've been seeing.
Please confirm the target release for these changes, so we could better help with testing.
this is already in insider's and will be released to stable the first week of July
Thanks, Megan. I'm travelling and don't have time for playing with Insiders ATM. Will wait for next release and use separate tunnel for the time being.
Thank you. Will the fixes be implemented in the near future?
please see above at
I am on Red Hat Linux Enterprise. Same issue on 1.79.2. I solved with downgrade method (1.78.2)
I also have this problem,it 's so hard for me.I'dont kown why.extensive or use python programm?
Hey! Sorry I unpinned the issue by accident
Would like to add that I was having this problem with v 1.79.2 on Fedora Linux with Gnome desktop. I installed the insiders edition v1.80.0 and I no longer have this issue for what it's worth. I would get "The connection to the terminal's pty host process is unresponsive" and after about 2 minutes, the terminal would finally show up. Comes up instantly in 1.80.0
This message comes up on 1.79.2 startup but disappears after a short while.
Why is this closed, the problem still exists.
It's fixed in 1.80+ so I guess there's no reason to keep it open.
Sorry about the hassle all, this is fixed in v1.80.0 which we're targeting to release Thursday the 6th ~11am PST

Discussion:
*/ BeatInterval = 5000, /** <ins> * The duration of the first heartbeat while the pty host is starting up. This is much larger * than the regular BeatInterval to accomodate slow machines, we still want to warn about the * pty host's unresponsiveness eventually though. */ ConnectingBeatInterval = 20000, /** </ins> * Defines a multiplier for BeatInterval for how long to wait before starting the second wait * timer. */

// Setup heartbeat service and trigger a heartbeat immediately to reset the timeouts const heartbeatService = ProxyChannel.toService<IHeartbeatService>(client.getChannel(TerminalIpcChannels.Heartbeat)); heartbeatService.onBeat(() => this._handleHeartbeat()); <del> // TODO: Starting the heartbeat tracking now causes problems this._handleHeartbeat(); </del> <ins> this._handleHeartbeat(true); </ins> // Handle exit this._register(connection.onDidProcessExit(e => {

this._connection.store.dispose(); } <del> private _handleHeartbeat() { </del> <ins> private _handleHeartbeat(isConnecting?: boolean) { </ins> this._clearHeartbeatTimeouts(); <del> this._heartbeatFirstTimeout = setTimeout(() => this._handleHeartbeatFirstTimeout(), HeartbeatConstants.BeatInterval * HeartbeatConstants.FirstWaitMultiplier); </del> <ins> this._heartbeatFirstTimeout = setTimeout(() => this._handleHeartbeatFirstTimeout(), isConnecting ? HeartbeatConstants.ConnectingBeatInterval : (HeartbeatConstants.BeatInterval * HeartbeatConstants.FirstWaitMultiplier)); </ins> if (!this._isResponsive) { this._isResponsive = true; this._onPtyHostResponsive.fire();