Connection to terminal's pty host process is becoming unresponsive

[triforcely]

Issue Type: Bug

After 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 (49af1cbe00271ac2ea36cfc5f7352fe31a7b0094, 2021-08-06T06:41:50.275Z) OS version: Windows_NT x64 10.0.19042 Restricted Mode: No

System Info

|Item|Value| |---|---| |CPUs|AMD Ryzen 9 3900X 12-Core Processor (24 x 3800)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|31.93GB (18.13GB free)| |Process Argv|--crash-reporter-id 99c6e3ee-c17a-4f3a-a118-c9cbac23e0db| |Screen Reader|no| |VM|0%|

Extensions (1)

Extension|Author (truncated)|Version ---|---|--- csharp|ms-|1.23.14

A/B Experiments

``` vsliv695:30137379 vsins829:30139715 vsliv368:30146709 vsreu685:30147344 python383cf:30185419 pythonvspyt602:30291494 vspor879:30202332 vspor708:30202333 vspor363:30204092 pythonvspyt639:30291487 pythontb:30258533 pythonvspyt551:30291412 pythonptprofiler:30281269 vshan820:30294714 pythondataviewer:30285072 pythonvsuse255:30319630 vscod805:30301674 pythonvspyt200:30323110 vsccppwt:30312692 pythonvssor306:30340298 bridge0708:30335490 pygetstartedt2:30348854 dockerwalkthru:30348713 ```

Tasks hierarchy

```json { "label": "[Debug] Create base image for Api container", "command": "powershell", "args": [ "docker", "build", "--rm", "-f", "${workspaceFolder}/BaseImage.Debug.Dockerfile", "-t", "baseimage-api-debug:latest", "." ] }, { "label": "[Debug] Create image for Api.Dockerfile", "command": "powershell", "args": [ "docker", "build", "--rm", "-f", "${workspaceFolder}/Api.Dockerfile", "-t", "backend-core-debug:latest", "." ], "problemMatcher": { "base": "$msCompile", "fileLocation": [ "relative", "${workspaceRoot}" ] }, "dependsOn": [ "[Debug] Create base image for Api container" ] }, { "label": "[Debug] Create image for Hangfire.Server.Dockerfile", "command": "powershell", "args": [ "docker", "build", "--rm", "-f", "${workspaceFolder}/Hangfire.Server.Dockerfile", "-t", "hangfire-server-debug:latest", "." ], "problemMatcher": { "base": "$msCompile", "fileLocation": [ "relative", "${workspaceRoot}" ] }, "dependsOn": [ "[Debug] Create base image for Api container" ] }, { "label": "[Debug] Create service for docker-compose.dev.yml", "command": "powershell", "args": [ "docker-compose", "-f", "${workspaceFolder}/docker-compose.dev.yml", "up", "-d", "--build", "--force-recreate", "--renew-anon-volumes" ], "problemMatcher": "$msCompile", "dependsOn": [ "[Debug] Create image for Api.Dockerfile", "[Debug] Create image for Hangfire.Server.Dockerfile" ] }, { "label": "[TS] generate libraries", "type": "shell", "command": "\"${workspaceRoot}/../_scripts/wait-for-it-http.ps1\" && nswag.cmd run || docker logs backend-core_api_1", "problemMatcher": "$msCompile", "options": { "cwd": "${workspaceRoot}/../tt-ts-core" }, "dependsOn": [ "[Debug] Create service for docker-compose.dev.yml" ] } ```

[JBaczuk]

Every time I wake my mac up from sleep (since the latest update to 1.59.1) 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.

[xianghongai]

"terminal.integrated.windowsEnableConpty": false

restart vs code ...

[xianghongai]

Duplicate of #117956, #118606

[Tyriar]

@xianghongai that issue should be fixed already.

[Airmail50]

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.

[lorand-horvath]

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....

[lorand-horvath]

@meganrogge I'm trying to find a solution to this annoying issue. Can you point me in the right direction, please?

[lorand-horvath]

@meganrogge 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?

[Tyriar]

@lorand-horvath you should update windows, Windows 7 was EOL in 2020 https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information#:~:text=After%2010%20years%2C%20support%20for,ended%20on%20January%2014%2C%202020. Also you never got to use conpty as it's only in the later versions of Windows 10.

[lorand-horvath]

@meganrogge @Tyriar 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 The pty host became responsive again so I get a series of the following connection lost/restored cycles:

The connection to the terminal's pty host process is unresponsive, the terminals may stop working.
INFO The pty host became responsive again

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!

[Tyriar]

Here are the timeouts related to the pty host heartbeat/responsiveness:

https://github.com/microsoft/vscode/blob/f6786c8f2ccf01a8aae2bbc0a3ef114b44a4a845/src/vs/platform/terminal/common/terminal.ts#L368-L390

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.

[lorand-horvath]

@Tyriar 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 Node.js 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. --disable-features=CalculateNativeWinOcclusion. Is there anything similar that we can use in this case for debugging? Even a temporary access to the BeatInterval value you mentioned, in the next Insiders release, would be valuable. Thanks again!

Edit: I see there's another parameter GraceTime = 60000 described as If there is no reconnection within this time-frame, consider the connection permanently closed.. 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.

[lorand-horvath]

@Tyriar I've been investigating by increasing the BeatInterval value above 5000 in C:\Program Files\Microsoft VS Code Insiders\resources\app\out\vs\platform\terminal\node\ptyHostMain.js. 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...

[lorand-horvath]

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?

[renzedj]

Having this same issue in macOS as of today. Per @meganrogge recommendation on #156668, I set terminal.integrated.enablePersistentSessions: false, but am still having this issue. It's persisted through a complete wipe of settings and a fresh install.

[meganrogge]

Thanks for your patience @drenze-athene 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

[renzedj]

Thanks for your patience @drenze-athene 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.

[renzedj]

@meganrogge -

Thanks for your patience @drenze-athene 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

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.

[lorand-horvath]

[dylankb]

For MacOS folks that get referred here terminal.integrated.enablePersistentSessions: false fixed the issue for me.

[lorand-horvath]

@dylankb I've just tested it and does NOT fix the issue for me. Still getting in the terminal: Assertion failed: new_time >= loop->time, file c:\ws\deps\uv\src\win\core.c, line 324 and then the notification pops up: The connection to the terminal's pty host process is unresponsive, the terminals may stop working.

[dylankb]

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 https://github.com/microsoft/vscode/issues/147192?

Things I tried:

• Also set terminal.integrated.persistentSessionReviveProcess: false per this comment
• Tried to "disable" the terminal following instructions in this post so now Terminal does not show up along side the Debug Console, Output, etc. panels. This may just have changed the panel UIs, though.

[giopalma]

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)

[dylankb]

Update: Upgrading my mac OS to Monterey solved the issue. I have no idea why.

While this is causing problems, is there a way to completely disable the integrated terminal or the pty host process?

Any thoughts whether this is possible @Tyriar @meganrogge ? 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?

[lorand-horvath]

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.

[Dllcx]

@lorand-horvath 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.

[Tyriar]

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?

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:

https://github.com/microsoft/vscode/blob/510f84046f9d7f009bebd1df6889f081e1640397/src/vs/platform/terminal/node/heartbeatService.ts#L17-L19

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.

While this is causing problems, is there a way to completely disable the integrated terminal or the pty host process?

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.

[lorand-horvath]

@Tyriar 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)...

[Tyriar]

@lorand-horvath 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).

[lorand-horvath]

@Tyriar 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...

[DanaSis]

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 (terminal.integrated.persistentSessionReviveProcess: false, 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 🙏

[rob1st]

Having the same issue: OS: Windows 10 Hone VS Code Version: 1.73.1

[lorand-horvath]

I've discovered that this issue is in fact caused by Node.js 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: Assertion failed: new_time >= loop->time, file c:\ws\deps\uv\src\win\core.c, line 324 and then, a few seconds later, VSCode pops up the notification Connection to terminal's pty host process is becoming unresponsive.

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 Node.js 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 Node.js doesn't solve the issue.

Any ideas what can be done?

[Dllcx]

Thank you very much, @lorand-horvath, 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!

[lorand-horvath]

@Dllcx 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.

[lorand-horvath]

@Dllcx 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.

[Dllcx]

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.19044.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;

[lorand-horvath]

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.

[lorand-horvath]

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...

[tjKairos]

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: 0615c4f98b07b51d3be6a357e22afec119490c5a Date: 2023-01-31T00:03:50.170Z Electron: 19.1.9 Chromium: 102.0.5005.194 Node.js: 16.14.2 V8: 10.2.154.23-electron.0 OS: Windows_NT x64 10.0.22621 Sandboxed: Yes

VSCode versions: Version: 1.74.3 (user setup) Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534 Date: 2023-01-09T16:59:02.252Z Electron: 19.1.8 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0.22621 Sandboxed: No

[lorand-horvath]

This error is most probably caused by the Electron bug https://github.com/electron/electron/issues/33868#issuecomment-1415955817

[bryan-bar]

Similar issue to @tjKairos , pty host process is becoming unresponsive when using v1.75.0, which is a part of the January 2023 release. Remote Pty Host under the Problems tab shows: [warning] Shell integration cannot be enabled for executable "/bin/sh" and args.

Upgraded to the latest release using Restart to Upgrade under the Help menu and could not use my terminal within VSCode: Version: 1.75.0 (user setup) Commit: e2816fe719a4026ffa1ee0189dc89bdfdbafb164 Date: 2023-02-01T15:23:45.584Z Electron: 19.1.9 Chromium: 102.0.5005.194 Node.js: 16.14.2 V8: 10.2.154.23-electron.0 OS: Windows_NT x64 10.0.22621 Sandboxed: No

Downgraded to November Release - v1.74.3 and able to use my terminal within VSCode again: Version: 1.74.3 (user setup) Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534 Date: 2023-01-09T16:59:02.252Z Electron: 19.1.8 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0.22621 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 v1.75.0. I went to settings, searched Update, change Update Mode to manual. To apply will require a restart which caused it to install the update for me again. I just ran the 1.74.3 installer again and good to go.

[muppet3000]

Similar issue to @tjKairos , pty host process is becoming unresponsive when using v1.75.0, which is a part of the January 2023 release. Remote Pty Host under the Problems tab shows: [warning] Shell integration cannot be enabled for executable "/bin/sh" and args.

Upgraded to the latest release using Restart to Upgrade under the Help menu and could not use my terminal within VSCode: Version: 1.75.0 (user setup) Commit: e2816fe Date: 2023-02-01T15:23:45.584Z Electron: 19.1.9 Chromium: 102.0.5005.194 Node.js: 16.14.2 V8: 10.2.154.23-electron.0 OS: Windows_NT x64 10.0.22621 Sandboxed: No

Downgraded to November Release - v1.74.3 and able to use my terminal within VSCode again: Version: 1.74.3 (user setup) Commit: 97dec17 Date: 2023-01-09T16:59:02.252Z Electron: 19.1.8 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0.22621 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 v1.75.0. I went to settings, searched Update, change Update Mode to manual. To apply will require a restart which caused it to install the update for me again. I just ran the 1.74.3 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.

[KernDerg]

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: e2816fe719a4026ffa1ee0189dc89bdfdbafb164 Date: 2023-02-01T15:23:45.584Z Electron: 19.1.9 Chromium: 102.0.5005.194 Node.js: 16.14.2 V8: 10.2.154.23-electron.0 OS: Windows_NT x64 10.0.19044 Sandboxed: No

[iolpltuisciaoln]

Version: 1.75.0 Commit: e2816fe719a4026ffa1ee0189dc89bdfdbafb164 Date: 2023-02-01T15:29:17.766Z Electron: 19.1.9 Chromium: 102.0.5005.194 Node.js: 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][0ac9c2ba][ManagementConnection] New connection established. 2023-02-09 09:22:31.477 [info] [127.0.0.1][4114cf3b][ExtensionHostConnection] New connection established. 2023-02-09 09:22:31.483 [info] [127.0.0.1][4114cf3b][ExtensionHostConnection] <210> Launched 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][0ac9c2ba][ManagementConnection] The client has reconnected. 2023-02-09 09:23:30.421 [info] [127.0.0.1][4114cf3b][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][0ac9c2ba][ManagementConnection] The client has disconnected gracefully, so the connection will be disposed. 2023-02-09 09:30:20.781 [info] [127.0.0.1][4114cf3b][ExtensionHostConnection] <210> Extension 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][0f752ed4][ManagementConnection] New connection established. 2023-02-09 09:30:26.541 [info] [127.0.0.1][d2eea1c1][ExtensionHostConnection] New connection established. 2023-02-09 09:30:26.549 [info] [127.0.0.1][d2eea1c1][ExtensionHostConnection] <2544> Launched Extension Host Process. 2023-02-09 09:30:32.187 [error] Error: disposed at p.k (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:22129) at Object.call (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:22016) at /root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:90:45272 at p.invoke (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:145) at v.deliver (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:2034) at u.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:1672) at I.setLogLevel (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:90:7239) at w.call (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:90:44826) at s (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:76:5518) at s.q (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:76:4992) at /root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:76:4377 at p.invoke (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:145) at v.deliver (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:2034) at u.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:1672) at A.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:14899) at s.E (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:18993) at /root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:16965 at p.invoke (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:145) at v.deliver (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:2034) at u.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:1672) at h.acceptChunk (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:12624) at /root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:11909 at p.invoke (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:145) at v.deliver (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:2034) at u.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:1672) at u.t (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:31826) 2023-02-09 09:30:32.189 [error] Error: disposed at p.k (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:22129) at Object.call (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:22016) at /root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:90:45272 at p.invoke (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:145) at v.deliver (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:2034) at u.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:1672) at I.setLogLevel (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:90:7239) at w.call (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:90:44826) at s (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:76:5518) at s.q (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:76:4992) at /root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:76:4377 at p.invoke (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:145) at v.deliver (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:2034) at u.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:1672) at A.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:14899) at s.E (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:18993) at /root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:16965 at p.invoke (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:145) at v.deliver (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:2034) at u.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:1672) at h.acceptChunk (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:12624) at /root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:11909 at p.invoke (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:145) at v.deliver (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:2034) at u.fire (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:66:1672) at u.t (/root/.vscode-server/bin/e2816fe719a4026ffa1ee0189dc89bdfdbafb164/out/vs/server/node/server.main.js:78:31826) 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

[Igetin]

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: https://github.com/microsoft/vscode-remote-release/issues/7999

[yaayes]

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: sudo dnf downgrade code.

[joezappie]

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.

[Aetherbase]

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 @deepak1556

[extrange]

I am unable to connect to terminals in any remote docker host as well (both privileged and non-privileged).