Question:
I just reloaded a window with my repo open, and it attached to a terminal which is already open in my repo, so now this terminal is open in two windows: ! The right window is the window that originally owned this terminal One thing about this terminal is that its cwd is some other folder outside of both workspaces, if that matters.
I reloaded the left window again, and it reattached to the correct terminal. !
Just so you know, this happens pretty often. I just reloaded a window and got some random terminal from another window. Let me know if I can collect any other info
Also hit this, I believe it was after restarting insiders for an update. !
I was able to repro once out of many attempts. I wonder if there's a command to reload all windows to simulate what happens on update? Maybe then I'd see it?
exiting the application (cmd+q) and reopening it is essentially what happens on update
Something similar just happened with the most recent insiders update, but now the terminals aren't synced, it's just that the working directory of one window's terminal is set to the other window's root instead of it's own. <img width="1440" alt="image" src="https://user-"
Happened again, accidentally ran a destructive command in the wrong directory :( cc is there any logging or something I can enable to help you get to the bottom of this?
I spent awhile investigating. I don't understand what could be going on here because we store and reconnect to terminals according to the workspaceId. said that he thinks it's a race condition. Setting log level to trace and toggling the shared process would help when it reproes
Today I had something new happen: had 3 VS Code windows open. reloaded window 1. 1 now shares a terminal with window 3! Totally different workspaces. No other windows were reloaded. No windows were closed. Is there a way I can disable terminal reconnect for local windows? I've also run destructive commands when this happens and I don't want to risk it.
Yep, it's not working atm for remote terminals, so:
Hello everyone, there is any plan to try to fix it in the nearest milestone?
This code that we for transferring terminals via dnd between windows looks suspicious
Has anyone seen this in awhile? I cannot reproduce
I don't remember seeing it recently
Okay pls reopen if you see it again and I'll be happy to debug with anyone that can reproduce it
Sorry, I cursed myself because this happened again today but I probably won't have consistent repro steps. I reloaded the window with my vscode workspace and got a terminal from this extension sample which is also open in another window, although the terminal panel had not been made visible in that other window's session yet. I reloaded the window several more times and always got the right terminal after that. <img width="1049" alt="image" src="https://user-"
we don't create a terminal until you open the panel, so what do you mean by the terminal had not been made visible yet?
In case it is important to the issue, I'm just saying that the drop-on-document terminal that was wrongly attached to the vscode window hadn't yet been attached to the drop-on-document window, because it was from some earlier session.
I also used to see this periodically but I've had terminal reattach disabled to avoid it. Let me know if it will be helpful and I'll re-enable reattach!
Same as
Yes it would be very helpful I spent 90 mins yesterday trying to reproduce to no avail. If you could enable trace logging too in case you repro, that might give the insight we need
We should review the code around terminal adoption of orphan processes, I suspect the issue is that it's not transactional.
it appears we're only doing an orphan check on terminals that are in the workspace as set in the map
I think somewhere all unadopted processes get taken by some window? Might not be remembering right though.
If you see this again after lands, please enable trace logging and get the output channel logs for Pty Host and Window.
I was seeing this previously on occasion but haven't seen it over the last week so marking as verified
+1 on no longer seeing it since re-enabling re-attach a few weeks ago.
Just saw this again. The incorrect re-attach occurred on 1 July and I only noticed it today. Pty logs: Window logs
This seemed for a while like it'd stopped happening, but just ran into it again: In my case I'd just reloaded a single window.
Just had this happen again, but once again I didn't have trace logging on. I'll try to leave it turned on for next time. Pty Host logs: Window logs:
Could the needed log statement to troubleshoot this on the terminal side be converted to an log. That might help track down this bug sooner.
they're actually warnings already so they should show up:
Just ran into this again. I have the same terminal restored in two distinct windows. I ran into this after restarting to update Insiders on macOS (I had 6 folders opened). The Pty Host log contains the following: https://user- Maybe might know if there's a way to easily simulate a restart caused by an update. Alternatively, maybe you can try changing a setting like which shows the restart prompt. I think this also leads to the terminals attaching incorrectly.
Might be related to (maybe not as that's remote only?)
this is a little confusing to me. No reconnect is meant to happen on restart, when updating node-pty gets replaced so it can't be running, all processes are torn down and the pty host shuts down with the main process. Did you see this? !
Changing this to always return isOrphan = true: I can get it to reconnect which is meant to be prevented by one of my other changes.
It's a little suspicious that the entry doesn't get deleted: That determines here which can bypass the orphan check:
I can confirm that within the last two days (both before and after the upgrade to 1.70.0) it has happened to me both on window reload and on full VSCode restart.
When I see this it also happen on restart.
do you see the history restored message when it happens on restart?
Yes, I see this every time when restarting to install a new version (Gear Restart to Update) or when changing the setting : <img width="473" alt="image" src="https://user-"
I'm 99.9% certain the answer is yes, but I will make sure to notice the next time it happens.
Ok, I figured this out. What a journey! Here is the fairly reliable repro: Clear state - Given 2 folders and Open folders and and close all terminals File Exit Setup for the process revive - Window : Open 3 terminals and type "a", "b", "c" into them respectively, this helps identify them to ensure they're in the correct order later Window : Open 3 terminals and type "d", "e", "f" into them respectively File Exit Process revive - Window and should revive the processes and have all terminals in the correct order they were created (this works) Process reconnect Reload window and window at the same time Window and should revive the processes and have all terminals in the correct order they were created :bug: Note that this is a timing issue and has a chance to not reproduce the problem. This is what is meant to happen when exiting and restarting the pty host process. Terminal processes are revived (aka. re-created) and their actual pty IDs for this pty host process are mapped to, starting at 1. Notice below how the new IDs start from 1, they just represent the order they are created in which shouldn't matter when reviving. After that, when reloading windows, terminal processes do not get revived but reconnected to. So an mapping is expected: What is happening and what is causing this bug as well as a related issue[^1] is that the revived pty ID is cached, so if reloading happens to use a that is mapped to a different pty ID in , it will reconnect to that one instead: The above results in: Then on reload the pty ID mapping occurs instead of being undefined, which causes a reconnect_ to the wrong pty. So in the above they get re-mapped, shuffling the order within a window and potentially connecting to a different window's ptys: ! [^1]: The folder's terminals may not get restored at with the warning "Couldn't get layout info, a terminal was probably disconnected" in the pty host output channel. This started happening due to one of the previous workarounds to prevent 2 windows attaching to the same pty.
Wow. Nice detective work! Thanks, looking forward to the fix.
Reported here
I actually saw it again once earlier this week too. It does seem to happen significantly less often than it used to.
I just ran into this again today. After a restart due to an update, I got a terminal from a folder showing up by itself in folder . Here's the only relevant content I found in my logs:
I hit this today. Moving this forward to January 2023, since it probably was just lost in the queries by being assigned to August 2022.
I've hit this once per day for the past several days. It seems to be occurring more frequently again.
This would probably be addressed if terminals moved into utility process and there was a message port per terminal:
Using the new pty host trace logging, this is what happens on a reload with a single terminal that will be reconnected, with the environment parts truncated:
I believe this is now fixed as a part of I'm still not able to reproduce but the current theory is that the async isOrphan check that was removed in the PR was not only delaying reconnection by 4 seconds, but also causing a race where the wrong window could adopt it. Instead we no longer check whether it's an orphan and trust the saved workplace state to be correct.
Thanks for following up
I haven't seen this in a long time. Not sure whether there is anything that can be done to verify it.
I just ran into this now: had ~4 windows open: Window 1 is vscode-pull-request-github2 : terminals cwd were all in the workspace Window 2 is vscode-pull-request-github: terminals cwd were all in the workspace Window 3 is repo1: 2 terminals, both of which had a cwd outside the workspace Window 4 is vscode: terminals cwd were all in the workspace VS Code reattach: Window 1's terminals are correct Window 2 has reattached to one of Window 3's terminals and has lost it's original terminal Window 3's terminals are correct Window 4's terminals are correct. Pty logs from Window 2:
thanks for the info! Looking into it
I spent a few hours looking into this, here are my findings: This warning in the logs is common across recent failures: , I tried and tried but could not reproduce this on Insiders or OSS I'm adding more verbose logs to the info log level that gives me the old/new pty id mapping as well as dumping a bunch of info when the above error happens I looked into whether should be correct and while I found it could cause issues when the pty host restarts (), it seems like it should work after a restart I could the cwd being outside the workspace would make a difference as we don't even take that into account when reviving the proc () The management of would be a lot simpler if we moved the id to being a guid instead of a number, but that would be a shame as we then need to send the guid along the wire for pretty much every request to the pty host I looked into possible race conditions where could get stale/invalid values. Both a thorough review of the code and injecting timeouts (random, differing by window) into important calls didn't cause problems Current plan is to wait for to merge and await a repro with these logs present, then analyze them. I'll also likely be continuing to fiddle with terminal reconnection in debt week to improve perf further and reduce redundancies.
I'll keep an eye out for this and try to maintain a setup similar that one that I just saw it with, but I have to say, this has gotten so much better. I almost never see it.
I tried to repeat my setup before updating, and it did happen again. Setup: Window 1 is vscode-pull-request-github2 : terminal cwd is outside the workspace and on a different drive (C vs D) Window 2 is vscode-pull-request-github: terminals cwd were in the workspace Window 3 is repo1: terminal cws was in the workspace Window 4 is vscode: terminals cwd were all in the workspace After update: Window 1 is vscode-pull-request-github2 : has a new terminal Window 2 is vscode-pull-request-github: correct Window 3 is repo1: has attached to Window 2's terminal and now they share the same terminal Window 4 is vscode: correct Logs:
Thanks it seems there's some inconsistency with the layout info and the revived procs, so I suspect this silently error swallowing now: Added logs for that here: , I'll merge for July so you might not be able to test for a week but when you do please also grab the Terminal output log as this is renderer side.
Cross post
With logs in , I was able to reproduce the problem! ! The repro is very complicated, it is essentially trying to get into a state where 2+ windows have "old pty ids" that conflict with one another, and then increasing the latency of the pty host in order to force the race condition to show itself. these settings: default log level to trace all windows window 1 (W1) with folder A 1: Open 2 terminals 1: Close window 1: Open window 1: Open pty host log, you should see this: window 2 (W2) with folder B 2: Open 2 terminals 1: Close window 2: Close window VS Code (W2 should open) 2: Open pty host log, you should something like this: 2: Close window an external terminal and type another external terminal and type the commands in both terminals in quick succession 1|W2: Open pty host log, you should see something like this: The terminal with end up attaching to the wrong pty. The fix for this is simple, just add workspace ID as part of the key of the old id, so becomes . This should make conflicts impossible to occur.

})); } <del> attach(): void { </del> <ins> async attach(): Promise<void> { </ins> this._logService.trace('persistentTerminalProcess#attach', this._persistentProcessId); <ins> if (!this._disconnectRunner1.isScheduled() && !this._disconnectRunner2.isScheduled()) { // Something wrong happened if the disconnect runner is not canceled, this likely means // multiple windows attempted to attach. if (!await this._isOrphaned()) { throw new Error(`Cannot attach to persistent process "${this._persistentProcessId}", it is already adopted`); } this._logService.warn(`Persistent process "${this._persistentProcessId}": Process had no disconnect runners but was an orphan`); } </ins> this._disconnectRunner1.cancel(); this._disconnectRunner2.cancel(); }


Question:
I just reloaded a window with my repo open, and it attached to a terminal which is already open in my repo, so now this terminal is open in two windows: ! The right window is the window that originally owned this terminal One thing about this terminal is that its cwd is some other folder outside of both workspaces, if that matters.
I reloaded the left window again, and it reattached to the correct terminal. !
Just so you know, this happens pretty often. I just reloaded a window and got some random terminal from another window. Let me know if I can collect any other info
Also hit this, I believe it was after restarting insiders for an update. !
I was able to repro once out of many attempts. I wonder if there's a command to reload all windows to simulate what happens on update? Maybe then I'd see it?
exiting the application (cmd+q) and reopening it is essentially what happens on update
Something similar just happened with the most recent insiders update, but now the terminals aren't synced, it's just that the working directory of one window's terminal is set to the other window's root instead of it's own. <img width="1440" alt="image" src="https://user-"
Happened again, accidentally ran a destructive command in the wrong directory :( cc is there any logging or something I can enable to help you get to the bottom of this?
I spent awhile investigating. I don't understand what could be going on here because we store and reconnect to terminals according to the workspaceId. said that he thinks it's a race condition. Setting log level to trace and toggling the shared process would help when it reproes
Today I had something new happen: had 3 VS Code windows open. reloaded window 1. 1 now shares a terminal with window 3! Totally different workspaces. No other windows were reloaded. No windows were closed. Is there a way I can disable terminal reconnect for local windows? I've also run destructive commands when this happens and I don't want to risk it.
Yep, it's not working atm for remote terminals, so:
Hello everyone, there is any plan to try to fix it in the nearest milestone?
This code that we for transferring terminals via dnd between windows looks suspicious
Has anyone seen this in awhile? I cannot reproduce
I don't remember seeing it recently
Okay pls reopen if you see it again and I'll be happy to debug with anyone that can reproduce it
Sorry, I cursed myself because this happened again today but I probably won't have consistent repro steps. I reloaded the window with my vscode workspace and got a terminal from this extension sample which is also open in another window, although the terminal panel had not been made visible in that other window's session yet. I reloaded the window several more times and always got the right terminal after that. <img width="1049" alt="image" src="https://user-"
we don't create a terminal until you open the panel, so what do you mean by the terminal had not been made visible yet?
In case it is important to the issue, I'm just saying that the drop-on-document terminal that was wrongly attached to the vscode window hadn't yet been attached to the drop-on-document window, because it was from some earlier session.
I also used to see this periodically but I've had terminal reattach disabled to avoid it. Let me know if it will be helpful and I'll re-enable reattach!
Same as
Yes it would be very helpful I spent 90 mins yesterday trying to reproduce to no avail. If you could enable trace logging too in case you repro, that might give the insight we need
We should review the code around terminal adoption of orphan processes, I suspect the issue is that it's not transactional.
it appears we're only doing an orphan check on terminals that are in the workspace as set in the map
I think somewhere all unadopted processes get taken by some window? Might not be remembering right though.
If you see this again after lands, please enable trace logging and get the output channel logs for Pty Host and Window.
I was seeing this previously on occasion but haven't seen it over the last week so marking as verified
+1 on no longer seeing it since re-enabling re-attach a few weeks ago.
Just saw this again. The incorrect re-attach occurred on 1 July and I only noticed it today. Pty logs: Window logs
This seemed for a while like it'd stopped happening, but just ran into it again: In my case I'd just reloaded a single window.
Just had this happen again, but once again I didn't have trace logging on. I'll try to leave it turned on for next time. Pty Host logs: Window logs:
Could the needed log statement to troubleshoot this on the terminal side be converted to an log. That might help track down this bug sooner.
they're actually warnings already so they should show up:
Just ran into this again. I have the same terminal restored in two distinct windows. I ran into this after restarting to update Insiders on macOS (I had 6 folders opened). The Pty Host log contains the following: https://user- Maybe might know if there's a way to easily simulate a restart caused by an update. Alternatively, maybe you can try changing a setting like which shows the restart prompt. I think this also leads to the terminals attaching incorrectly.
Might be related to (maybe not as that's remote only?)
this is a little confusing to me. No reconnect is meant to happen on restart, when updating node-pty gets replaced so it can't be running, all processes are torn down and the pty host shuts down with the main process. Did you see this? !
Changing this to always return isOrphan = true: I can get it to reconnect which is meant to be prevented by one of my other changes.
It's a little suspicious that the entry doesn't get deleted: That determines here which can bypass the orphan check:
I can confirm that within the last two days (both before and after the upgrade to 1.70.0) it has happened to me both on window reload and on full VSCode restart.
When I see this it also happen on restart.
do you see the history restored message when it happens on restart?
Yes, I see this every time when restarting to install a new version (Gear Restart to Update) or when changing the setting : <img width="473" alt="image" src="https://user-"
I'm 99.9% certain the answer is yes, but I will make sure to notice the next time it happens.
Ok, I figured this out. What a journey! Here is the fairly reliable repro: Clear state - Given 2 folders and Open folders and and close all terminals File Exit Setup for the process revive - Window : Open 3 terminals and type "a", "b", "c" into them respectively, this helps identify them to ensure they're in the correct order later Window : Open 3 terminals and type "d", "e", "f" into them respectively File Exit Process revive - Window and should revive the processes and have all terminals in the correct order they were created (this works) Process reconnect Reload window and window at the same time Window and should revive the processes and have all terminals in the correct order they were created :bug: Note that this is a timing issue and has a chance to not reproduce the problem. This is what is meant to happen when exiting and restarting the pty host process. Terminal processes are revived (aka. re-created) and their actual pty IDs for this pty host process are mapped to, starting at 1. Notice below how the new IDs start from 1, they just represent the order they are created in which shouldn't matter when reviving. After that, when reloading windows, terminal processes do not get revived but reconnected to. So an mapping is expected: What is happening and what is causing this bug as well as a related issue[^1] is that the revived pty ID is cached, so if reloading happens to use a that is mapped to a different pty ID in , it will reconnect to that one instead: The above results in: Then on reload the pty ID mapping occurs instead of being undefined, which causes a reconnect_ to the wrong pty. So in the above they get re-mapped, shuffling the order within a window and potentially connecting to a different window's ptys: ! [^1]: The folder's terminals may not get restored at with the warning "Couldn't get layout info, a terminal was probably disconnected" in the pty host output channel. This started happening due to one of the previous workarounds to prevent 2 windows attaching to the same pty.
Wow. Nice detective work! Thanks, looking forward to the fix.
Reported here
I actually saw it again once earlier this week too. It does seem to happen significantly less often than it used to.
I just ran into this again today. After a restart due to an update, I got a terminal from a folder showing up by itself in folder . Here's the only relevant content I found in my logs:
I hit this today. Moving this forward to January 2023, since it probably was just lost in the queries by being assigned to August 2022.
I've hit this once per day for the past several days. It seems to be occurring more frequently again.
This would probably be addressed if terminals moved into utility process and there was a message port per terminal:
Using the new pty host trace logging, this is what happens on a reload with a single terminal that will be reconnected, with the environment parts truncated:
I believe this is now fixed as a part of I'm still not able to reproduce but the current theory is that the async isOrphan check that was removed in the PR was not only delaying reconnection by 4 seconds, but also causing a race where the wrong window could adopt it. Instead we no longer check whether it's an orphan and trust the saved workplace state to be correct.
Thanks for following up
I haven't seen this in a long time. Not sure whether there is anything that can be done to verify it.
I just ran into this now: had ~4 windows open: Window 1 is vscode-pull-request-github2 : terminals cwd were all in the workspace Window 2 is vscode-pull-request-github: terminals cwd were all in the workspace Window 3 is repo1: 2 terminals, both of which had a cwd outside the workspace Window 4 is vscode: terminals cwd were all in the workspace VS Code reattach: Window 1's terminals are correct Window 2 has reattached to one of Window 3's terminals and has lost it's original terminal Window 3's terminals are correct Window 4's terminals are correct. Pty logs from Window 2:
thanks for the info! Looking into it
I spent a few hours looking into this, here are my findings: This warning in the logs is common across recent failures: , I tried and tried but could not reproduce this on Insiders or OSS I'm adding more verbose logs to the info log level that gives me the old/new pty id mapping as well as dumping a bunch of info when the above error happens I looked into whether should be correct and while I found it could cause issues when the pty host restarts (), it seems like it should work after a restart I could the cwd being outside the workspace would make a difference as we don't even take that into account when reviving the proc () The management of would be a lot simpler if we moved the id to being a guid instead of a number, but that would be a shame as we then need to send the guid along the wire for pretty much every request to the pty host I looked into possible race conditions where could get stale/invalid values. Both a thorough review of the code and injecting timeouts (random, differing by window) into important calls didn't cause problems Current plan is to wait for to merge and await a repro with these logs present, then analyze them. I'll also likely be continuing to fiddle with terminal reconnection in debt week to improve perf further and reduce redundancies.
I'll keep an eye out for this and try to maintain a setup similar that one that I just saw it with, but I have to say, this has gotten so much better. I almost never see it.
I tried to repeat my setup before updating, and it did happen again. Setup: Window 1 is vscode-pull-request-github2 : terminal cwd is outside the workspace and on a different drive (C vs D) Window 2 is vscode-pull-request-github: terminals cwd were in the workspace Window 3 is repo1: terminal cws was in the workspace Window 4 is vscode: terminals cwd were all in the workspace After update: Window 1 is vscode-pull-request-github2 : has a new terminal Window 2 is vscode-pull-request-github: correct Window 3 is repo1: has attached to Window 2's terminal and now they share the same terminal Window 4 is vscode: correct Logs:
Thanks it seems there's some inconsistency with the layout info and the revived procs, so I suspect this silently error swallowing now: Added logs for that here: , I'll merge for July so you might not be able to test for a week but when you do please also grab the Terminal output log as this is renderer side.
Cross post
With logs in , I was able to reproduce the problem! ! The repro is very complicated, it is essentially trying to get into a state where 2+ windows have "old pty ids" that conflict with one another, and then increasing the latency of the pty host in order to force the race condition to show itself. these settings: default log level to trace all windows window 1 (W1) with folder A 1: Open 2 terminals 1: Close window 1: Open window 1: Open pty host log, you should see this: window 2 (W2) with folder B 2: Open 2 terminals 1: Close window 2: Close window VS Code (W2 should open) 2: Open pty host log, you should something like this: 2: Close window an external terminal and type another external terminal and type the commands in both terminals in quick succession 1|W2: Open pty host log, you should see something like this: The terminal with end up attaching to the wrong pty. The fix for this is simple, just add workspace ID as part of the key of the old id, so becomes . This should make conflicts impossible to occur.

this._dimensions.rows = rows; this._isScreenReaderModeEnabled = isScreenReaderModeEnabled; <del> let newProcess: ITerminalChildProcess; </del> <ins> let newProcess: ITerminalChildProcess | undefined; </ins> if (shellLaunchConfig.customPtyImplementation) { this._processType = ProcessType.PsuedoTerminal;


Question:
I just reloaded a window with my repo open, and it attached to a terminal which is already open in my repo, so now this terminal is open in two windows: ! The right window is the window that originally owned this terminal One thing about this terminal is that its cwd is some other folder outside of both workspaces, if that matters.
I reloaded the left window again, and it reattached to the correct terminal. !
Just so you know, this happens pretty often. I just reloaded a window and got some random terminal from another window. Let me know if I can collect any other info
Also hit this, I believe it was after restarting insiders for an update. !
I was able to repro once out of many attempts. I wonder if there's a command to reload all windows to simulate what happens on update? Maybe then I'd see it?
exiting the application (cmd+q) and reopening it is essentially what happens on update
Something similar just happened with the most recent insiders update, but now the terminals aren't synced, it's just that the working directory of one window's terminal is set to the other window's root instead of it's own. <img width="1440" alt="image" src="https://user-"
Happened again, accidentally ran a destructive command in the wrong directory :( cc is there any logging or something I can enable to help you get to the bottom of this?
I spent awhile investigating. I don't understand what could be going on here because we store and reconnect to terminals according to the workspaceId. said that he thinks it's a race condition. Setting log level to trace and toggling the shared process would help when it reproes
Today I had something new happen: had 3 VS Code windows open. reloaded window 1. 1 now shares a terminal with window 3! Totally different workspaces. No other windows were reloaded. No windows were closed. Is there a way I can disable terminal reconnect for local windows? I've also run destructive commands when this happens and I don't want to risk it.
Yep, it's not working atm for remote terminals, so:
Hello everyone, there is any plan to try to fix it in the nearest milestone?
This code that we for transferring terminals via dnd between windows looks suspicious
Has anyone seen this in awhile? I cannot reproduce
I don't remember seeing it recently
Okay pls reopen if you see it again and I'll be happy to debug with anyone that can reproduce it
Sorry, I cursed myself because this happened again today but I probably won't have consistent repro steps. I reloaded the window with my vscode workspace and got a terminal from this extension sample which is also open in another window, although the terminal panel had not been made visible in that other window's session yet. I reloaded the window several more times and always got the right terminal after that. <img width="1049" alt="image" src="https://user-"
we don't create a terminal until you open the panel, so what do you mean by the terminal had not been made visible yet?
In case it is important to the issue, I'm just saying that the drop-on-document terminal that was wrongly attached to the vscode window hadn't yet been attached to the drop-on-document window, because it was from some earlier session.
I also used to see this periodically but I've had terminal reattach disabled to avoid it. Let me know if it will be helpful and I'll re-enable reattach!
Same as
Yes it would be very helpful I spent 90 mins yesterday trying to reproduce to no avail. If you could enable trace logging too in case you repro, that might give the insight we need
We should review the code around terminal adoption of orphan processes, I suspect the issue is that it's not transactional.
it appears we're only doing an orphan check on terminals that are in the workspace as set in the map
I think somewhere all unadopted processes get taken by some window? Might not be remembering right though.
If you see this again after lands, please enable trace logging and get the output channel logs for Pty Host and Window.
I was seeing this previously on occasion but haven't seen it over the last week so marking as verified
+1 on no longer seeing it since re-enabling re-attach a few weeks ago.
Just saw this again. The incorrect re-attach occurred on 1 July and I only noticed it today. Pty logs: Window logs
This seemed for a while like it'd stopped happening, but just ran into it again: In my case I'd just reloaded a single window.
Just had this happen again, but once again I didn't have trace logging on. I'll try to leave it turned on for next time. Pty Host logs: Window logs:
Could the needed log statement to troubleshoot this on the terminal side be converted to an log. That might help track down this bug sooner.
they're actually warnings already so they should show up:
Just ran into this again. I have the same terminal restored in two distinct windows. I ran into this after restarting to update Insiders on macOS (I had 6 folders opened). The Pty Host log contains the following: https://user- Maybe might know if there's a way to easily simulate a restart caused by an update. Alternatively, maybe you can try changing a setting like which shows the restart prompt. I think this also leads to the terminals attaching incorrectly.
Might be related to (maybe not as that's remote only?)
this is a little confusing to me. No reconnect is meant to happen on restart, when updating node-pty gets replaced so it can't be running, all processes are torn down and the pty host shuts down with the main process. Did you see this? !
Changing this to always return isOrphan = true: I can get it to reconnect which is meant to be prevented by one of my other changes.
It's a little suspicious that the entry doesn't get deleted: That determines here which can bypass the orphan check:
I can confirm that within the last two days (both before and after the upgrade to 1.70.0) it has happened to me both on window reload and on full VSCode restart.
When I see this it also happen on restart.
do you see the history restored message when it happens on restart?
Yes, I see this every time when restarting to install a new version (Gear Restart to Update) or when changing the setting : <img width="473" alt="image" src="https://user-"
I'm 99.9% certain the answer is yes, but I will make sure to notice the next time it happens.
Ok, I figured this out. What a journey! Here is the fairly reliable repro: Clear state - Given 2 folders and Open folders and and close all terminals File Exit Setup for the process revive - Window : Open 3 terminals and type "a", "b", "c" into them respectively, this helps identify them to ensure they're in the correct order later Window : Open 3 terminals and type "d", "e", "f" into them respectively File Exit Process revive - Window and should revive the processes and have all terminals in the correct order they were created (this works) Process reconnect Reload window and window at the same time Window and should revive the processes and have all terminals in the correct order they were created :bug: Note that this is a timing issue and has a chance to not reproduce the problem. This is what is meant to happen when exiting and restarting the pty host process. Terminal processes are revived (aka. re-created) and their actual pty IDs for this pty host process are mapped to, starting at 1. Notice below how the new IDs start from 1, they just represent the order they are created in which shouldn't matter when reviving. After that, when reloading windows, terminal processes do not get revived but reconnected to. So an mapping is expected: What is happening and what is causing this bug as well as a related issue[^1] is that the revived pty ID is cached, so if reloading happens to use a that is mapped to a different pty ID in , it will reconnect to that one instead: The above results in: Then on reload the pty ID mapping occurs instead of being undefined, which causes a reconnect_ to the wrong pty. So in the above they get re-mapped, shuffling the order within a window and potentially connecting to a different window's ptys: ! [^1]: The folder's terminals may not get restored at with the warning "Couldn't get layout info, a terminal was probably disconnected" in the pty host output channel. This started happening due to one of the previous workarounds to prevent 2 windows attaching to the same pty.
Wow. Nice detective work! Thanks, looking forward to the fix.
Reported here
I actually saw it again once earlier this week too. It does seem to happen significantly less often than it used to.
I just ran into this again today. After a restart due to an update, I got a terminal from a folder showing up by itself in folder . Here's the only relevant content I found in my logs:
I hit this today. Moving this forward to January 2023, since it probably was just lost in the queries by being assigned to August 2022.
I've hit this once per day for the past several days. It seems to be occurring more frequently again.
This would probably be addressed if terminals moved into utility process and there was a message port per terminal:
Using the new pty host trace logging, this is what happens on a reload with a single terminal that will be reconnected, with the environment parts truncated:
I believe this is now fixed as a part of I'm still not able to reproduce but the current theory is that the async isOrphan check that was removed in the PR was not only delaying reconnection by 4 seconds, but also causing a race where the wrong window could adopt it. Instead we no longer check whether it's an orphan and trust the saved workplace state to be correct.
Thanks for following up
I haven't seen this in a long time. Not sure whether there is anything that can be done to verify it.
I just ran into this now: had ~4 windows open: Window 1 is vscode-pull-request-github2 : terminals cwd were all in the workspace Window 2 is vscode-pull-request-github: terminals cwd were all in the workspace Window 3 is repo1: 2 terminals, both of which had a cwd outside the workspace Window 4 is vscode: terminals cwd were all in the workspace VS Code reattach: Window 1's terminals are correct Window 2 has reattached to one of Window 3's terminals and has lost it's original terminal Window 3's terminals are correct Window 4's terminals are correct. Pty logs from Window 2:
thanks for the info! Looking into it
I spent a few hours looking into this, here are my findings: This warning in the logs is common across recent failures: , I tried and tried but could not reproduce this on Insiders or OSS I'm adding more verbose logs to the info log level that gives me the old/new pty id mapping as well as dumping a bunch of info when the above error happens I looked into whether should be correct and while I found it could cause issues when the pty host restarts (), it seems like it should work after a restart I could the cwd being outside the workspace would make a difference as we don't even take that into account when reviving the proc () The management of would be a lot simpler if we moved the id to being a guid instead of a number, but that would be a shame as we then need to send the guid along the wire for pretty much every request to the pty host I looked into possible race conditions where could get stale/invalid values. Both a thorough review of the code and injecting timeouts (random, differing by window) into important calls didn't cause problems Current plan is to wait for to merge and await a repro with these logs present, then analyze them. I'll also likely be continuing to fiddle with terminal reconnection in debt week to improve perf further and reduce redundancies.
I'll keep an eye out for this and try to maintain a setup similar that one that I just saw it with, but I have to say, this has gotten so much better. I almost never see it.
I tried to repeat my setup before updating, and it did happen again. Setup: Window 1 is vscode-pull-request-github2 : terminal cwd is outside the workspace and on a different drive (C vs D) Window 2 is vscode-pull-request-github: terminals cwd were in the workspace Window 3 is repo1: terminal cws was in the workspace Window 4 is vscode: terminals cwd were all in the workspace After update: Window 1 is vscode-pull-request-github2 : has a new terminal Window 2 is vscode-pull-request-github: correct Window 3 is repo1: has attached to Window 2's terminal and now they share the same terminal Window 4 is vscode: correct Logs:
Thanks it seems there's some inconsistency with the layout info and the revived procs, so I suspect this silently error swallowing now: Added logs for that here: , I'll merge for July so you might not be able to test for a week but when you do please also grab the Terminal output log as this is renderer side.
Cross post
With logs in , I was able to reproduce the problem! ! The repro is very complicated, it is essentially trying to get into a state where 2+ windows have "old pty ids" that conflict with one another, and then increasing the latency of the pty host in order to force the race condition to show itself. these settings: default log level to trace all windows window 1 (W1) with folder A 1: Open 2 terminals 1: Close window 1: Open window 1: Open pty host log, you should see this: window 2 (W2) with folder B 2: Open 2 terminals 1: Close window 2: Close window VS Code (W2 should open) 2: Open pty host log, you should something like this: 2: Close window an external terminal and type another external terminal and type the commands in both terminals in quick succession 1|W2: Open pty host log, you should see something like this: The terminal with end up attaching to the wrong pty. The fix for this is simple, just add workspace ID as part of the key of the old id, so becomes . This should make conflicts impossible to occur.

if (result) { newProcess = result; } else { <del> this._logService.trace(`Attach to process failed for terminal ${shellLaunchConfig.attachPersistentProcess}`); return undefined; </del> <ins> // Warn and just create a new terminal if attach failed for some reason this._logService.warn(`Attach to process failed for terminal`, shellLaunchConfig.attachPersistentProcess); shellLaunchConfig.attachPersistentProcess = undefined; </ins> } <del> } else { </del> <ins> } if (!newProcess) { </ins> await this._terminalProfileResolverService.resolveShellLaunchConfig(shellLaunchConfig, { remoteAuthority: this.remoteAuthority, os: this.os


Question:
I just reloaded a window with my repo open, and it attached to a terminal which is already open in my repo, so now this terminal is open in two windows: ! The right window is the window that originally owned this terminal One thing about this terminal is that its cwd is some other folder outside of both workspaces, if that matters.
I reloaded the left window again, and it reattached to the correct terminal. !
Just so you know, this happens pretty often. I just reloaded a window and got some random terminal from another window. Let me know if I can collect any other info
Also hit this, I believe it was after restarting insiders for an update. !
I was able to repro once out of many attempts. I wonder if there's a command to reload all windows to simulate what happens on update? Maybe then I'd see it?
exiting the application (cmd+q) and reopening it is essentially what happens on update
Something similar just happened with the most recent insiders update, but now the terminals aren't synced, it's just that the working directory of one window's terminal is set to the other window's root instead of it's own. <img width="1440" alt="image" src="https://user-"
Happened again, accidentally ran a destructive command in the wrong directory :( cc is there any logging or something I can enable to help you get to the bottom of this?
I spent awhile investigating. I don't understand what could be going on here because we store and reconnect to terminals according to the workspaceId. said that he thinks it's a race condition. Setting log level to trace and toggling the shared process would help when it reproes
Today I had something new happen: had 3 VS Code windows open. reloaded window 1. 1 now shares a terminal with window 3! Totally different workspaces. No other windows were reloaded. No windows were closed. Is there a way I can disable terminal reconnect for local windows? I've also run destructive commands when this happens and I don't want to risk it.
Yep, it's not working atm for remote terminals, so:
Hello everyone, there is any plan to try to fix it in the nearest milestone?
This code that we for transferring terminals via dnd between windows looks suspicious
Has anyone seen this in awhile? I cannot reproduce
I don't remember seeing it recently
Okay pls reopen if you see it again and I'll be happy to debug with anyone that can reproduce it
Sorry, I cursed myself because this happened again today but I probably won't have consistent repro steps. I reloaded the window with my vscode workspace and got a terminal from this extension sample which is also open in another window, although the terminal panel had not been made visible in that other window's session yet. I reloaded the window several more times and always got the right terminal after that. <img width="1049" alt="image" src="https://user-"
we don't create a terminal until you open the panel, so what do you mean by the terminal had not been made visible yet?
In case it is important to the issue, I'm just saying that the drop-on-document terminal that was wrongly attached to the vscode window hadn't yet been attached to the drop-on-document window, because it was from some earlier session.
I also used to see this periodically but I've had terminal reattach disabled to avoid it. Let me know if it will be helpful and I'll re-enable reattach!
Same as
Yes it would be very helpful I spent 90 mins yesterday trying to reproduce to no avail. If you could enable trace logging too in case you repro, that might give the insight we need
We should review the code around terminal adoption of orphan processes, I suspect the issue is that it's not transactional.
it appears we're only doing an orphan check on terminals that are in the workspace as set in the map
I think somewhere all unadopted processes get taken by some window? Might not be remembering right though.
If you see this again after lands, please enable trace logging and get the output channel logs for Pty Host and Window.
I was seeing this previously on occasion but haven't seen it over the last week so marking as verified
+1 on no longer seeing it since re-enabling re-attach a few weeks ago.
Just saw this again. The incorrect re-attach occurred on 1 July and I only noticed it today. Pty logs: Window logs
This seemed for a while like it'd stopped happening, but just ran into it again: In my case I'd just reloaded a single window.
Just had this happen again, but once again I didn't have trace logging on. I'll try to leave it turned on for next time. Pty Host logs: Window logs:
Could the needed log statement to troubleshoot this on the terminal side be converted to an log. That might help track down this bug sooner.
they're actually warnings already so they should show up:
Just ran into this again. I have the same terminal restored in two distinct windows. I ran into this after restarting to update Insiders on macOS (I had 6 folders opened). The Pty Host log contains the following: https://user- Maybe might know if there's a way to easily simulate a restart caused by an update. Alternatively, maybe you can try changing a setting like which shows the restart prompt. I think this also leads to the terminals attaching incorrectly.
Might be related to (maybe not as that's remote only?)
this is a little confusing to me. No reconnect is meant to happen on restart, when updating node-pty gets replaced so it can't be running, all processes are torn down and the pty host shuts down with the main process. Did you see this? !
Changing this to always return isOrphan = true: I can get it to reconnect which is meant to be prevented by one of my other changes.
It's a little suspicious that the entry doesn't get deleted: That determines here which can bypass the orphan check:
I can confirm that within the last two days (both before and after the upgrade to 1.70.0) it has happened to me both on window reload and on full VSCode restart.
When I see this it also happen on restart.
do you see the history restored message when it happens on restart?
Yes, I see this every time when restarting to install a new version (Gear Restart to Update) or when changing the setting : <img width="473" alt="image" src="https://user-"
I'm 99.9% certain the answer is yes, but I will make sure to notice the next time it happens.
Ok, I figured this out. What a journey! Here is the fairly reliable repro: Clear state - Given 2 folders and Open folders and and close all terminals File Exit Setup for the process revive - Window : Open 3 terminals and type "a", "b", "c" into them respectively, this helps identify them to ensure they're in the correct order later Window : Open 3 terminals and type "d", "e", "f" into them respectively File Exit Process revive - Window and should revive the processes and have all terminals in the correct order they were created (this works) Process reconnect Reload window and window at the same time Window and should revive the processes and have all terminals in the correct order they were created :bug: Note that this is a timing issue and has a chance to not reproduce the problem. This is what is meant to happen when exiting and restarting the pty host process. Terminal processes are revived (aka. re-created) and their actual pty IDs for this pty host process are mapped to, starting at 1. Notice below how the new IDs start from 1, they just represent the order they are created in which shouldn't matter when reviving. After that, when reloading windows, terminal processes do not get revived but reconnected to. So an mapping is expected: What is happening and what is causing this bug as well as a related issue[^1] is that the revived pty ID is cached, so if reloading happens to use a that is mapped to a different pty ID in , it will reconnect to that one instead: The above results in: Then on reload the pty ID mapping occurs instead of being undefined, which causes a reconnect_ to the wrong pty. So in the above they get re-mapped, shuffling the order within a window and potentially connecting to a different window's ptys: ! [^1]: The folder's terminals may not get restored at with the warning "Couldn't get layout info, a terminal was probably disconnected" in the pty host output channel. This started happening due to one of the previous workarounds to prevent 2 windows attaching to the same pty.
Wow. Nice detective work! Thanks, looking forward to the fix.
Reported here
I actually saw it again once earlier this week too. It does seem to happen significantly less often than it used to.
I just ran into this again today. After a restart due to an update, I got a terminal from a folder showing up by itself in folder . Here's the only relevant content I found in my logs:
I hit this today. Moving this forward to January 2023, since it probably was just lost in the queries by being assigned to August 2022.
I've hit this once per day for the past several days. It seems to be occurring more frequently again.
This would probably be addressed if terminals moved into utility process and there was a message port per terminal:
Using the new pty host trace logging, this is what happens on a reload with a single terminal that will be reconnected, with the environment parts truncated:
I believe this is now fixed as a part of I'm still not able to reproduce but the current theory is that the async isOrphan check that was removed in the PR was not only delaying reconnection by 4 seconds, but also causing a race where the wrong window could adopt it. Instead we no longer check whether it's an orphan and trust the saved workplace state to be correct.
Thanks for following up
I haven't seen this in a long time. Not sure whether there is anything that can be done to verify it.
I just ran into this now: had ~4 windows open: Window 1 is vscode-pull-request-github2 : terminals cwd were all in the workspace Window 2 is vscode-pull-request-github: terminals cwd were all in the workspace Window 3 is repo1: 2 terminals, both of which had a cwd outside the workspace Window 4 is vscode: terminals cwd were all in the workspace VS Code reattach: Window 1's terminals are correct Window 2 has reattached to one of Window 3's terminals and has lost it's original terminal Window 3's terminals are correct Window 4's terminals are correct. Pty logs from Window 2:
thanks for the info! Looking into it
I spent a few hours looking into this, here are my findings: This warning in the logs is common across recent failures: , I tried and tried but could not reproduce this on Insiders or OSS I'm adding more verbose logs to the info log level that gives me the old/new pty id mapping as well as dumping a bunch of info when the above error happens I looked into whether should be correct and while I found it could cause issues when the pty host restarts (), it seems like it should work after a restart I could the cwd being outside the workspace would make a difference as we don't even take that into account when reviving the proc () The management of would be a lot simpler if we moved the id to being a guid instead of a number, but that would be a shame as we then need to send the guid along the wire for pretty much every request to the pty host I looked into possible race conditions where could get stale/invalid values. Both a thorough review of the code and injecting timeouts (random, differing by window) into important calls didn't cause problems Current plan is to wait for to merge and await a repro with these logs present, then analyze them. I'll also likely be continuing to fiddle with terminal reconnection in debt week to improve perf further and reduce redundancies.
I'll keep an eye out for this and try to maintain a setup similar that one that I just saw it with, but I have to say, this has gotten so much better. I almost never see it.
I tried to repeat my setup before updating, and it did happen again. Setup: Window 1 is vscode-pull-request-github2 : terminal cwd is outside the workspace and on a different drive (C vs D) Window 2 is vscode-pull-request-github: terminals cwd were in the workspace Window 3 is repo1: terminal cws was in the workspace Window 4 is vscode: terminals cwd were all in the workspace After update: Window 1 is vscode-pull-request-github2 : has a new terminal Window 2 is vscode-pull-request-github: correct Window 3 is repo1: has attached to Window 2's terminal and now they share the same terminal Window 4 is vscode: correct Logs:
Thanks it seems there's some inconsistency with the layout info and the revived procs, so I suspect this silently error swallowing now: Added logs for that here: , I'll merge for July so you might not be able to test for a week but when you do please also grab the Terminal output log as this is renderer side.
Cross post
With logs in , I was able to reproduce the problem! ! The repro is very complicated, it is essentially trying to get into a state where 2+ windows have "old pty ids" that conflict with one another, and then increasing the latency of the pty host in order to force the race condition to show itself. these settings: default log level to trace all windows window 1 (W1) with folder A 1: Open 2 terminals 1: Close window 1: Open window 1: Open pty host log, you should see this: window 2 (W2) with folder B 2: Open 2 terminals 1: Close window 2: Close window VS Code (W2 should open) 2: Open pty host log, you should something like this: 2: Close window an external terminal and type another external terminal and type the commands in both terminals in quick succession 1|W2: Open pty host log, you should see something like this: The terminal with end up attaching to the wrong pty. The fix for this is simple, just add workspace ID as part of the key of the old id, so becomes . This should make conflicts impossible to occur.

if (result) { newProcess = result; } else { <del> this._logService.trace(`Attach to process failed for terminal ${shellLaunchConfig.attachPersistentProcess}`); return undefined; </del> <ins> // Warn and just create a new terminal if attach failed for some reason this._logService.warn(`Attach to process failed for terminal`, shellLaunchConfig.attachPersistentProcess); shellLaunchConfig.attachPersistentProcess = undefined; </ins> } <del> } else { </del> <ins> } if (!newProcess) { </ins> newProcess = await this._launchLocalProcess(backend, shellLaunchConfig, cols, rows, this.userHome, isScreenReaderModeEnabled, variableResolver); } if (!this._isDisposed) {


Question:
I just reloaded a window with my repo open, and it attached to a terminal which is already open in my repo, so now this terminal is open in two windows: ! The right window is the window that originally owned this terminal One thing about this terminal is that its cwd is some other folder outside of both workspaces, if that matters.
I reloaded the left window again, and it reattached to the correct terminal. !
Just so you know, this happens pretty often. I just reloaded a window and got some random terminal from another window. Let me know if I can collect any other info
Also hit this, I believe it was after restarting insiders for an update. !
I was able to repro once out of many attempts. I wonder if there's a command to reload all windows to simulate what happens on update? Maybe then I'd see it?
exiting the application (cmd+q) and reopening it is essentially what happens on update
Something similar just happened with the most recent insiders update, but now the terminals aren't synced, it's just that the working directory of one window's terminal is set to the other window's root instead of it's own. <img width="1440" alt="image" src="https://user-"
Happened again, accidentally ran a destructive command in the wrong directory :( cc is there any logging or something I can enable to help you get to the bottom of this?
I spent awhile investigating. I don't understand what could be going on here because we store and reconnect to terminals according to the workspaceId. said that he thinks it's a race condition. Setting log level to trace and toggling the shared process would help when it reproes
Today I had something new happen: had 3 VS Code windows open. reloaded window 1. 1 now shares a terminal with window 3! Totally different workspaces. No other windows were reloaded. No windows were closed. Is there a way I can disable terminal reconnect for local windows? I've also run destructive commands when this happens and I don't want to risk it.
Yep, it's not working atm for remote terminals, so:
Hello everyone, there is any plan to try to fix it in the nearest milestone?
This code that we for transferring terminals via dnd between windows looks suspicious
Has anyone seen this in awhile? I cannot reproduce
I don't remember seeing it recently
Okay pls reopen if you see it again and I'll be happy to debug with anyone that can reproduce it
Sorry, I cursed myself because this happened again today but I probably won't have consistent repro steps. I reloaded the window with my vscode workspace and got a terminal from this extension sample which is also open in another window, although the terminal panel had not been made visible in that other window's session yet. I reloaded the window several more times and always got the right terminal after that. <img width="1049" alt="image" src="https://user-"
we don't create a terminal until you open the panel, so what do you mean by the terminal had not been made visible yet?
In case it is important to the issue, I'm just saying that the drop-on-document terminal that was wrongly attached to the vscode window hadn't yet been attached to the drop-on-document window, because it was from some earlier session.
I also used to see this periodically but I've had terminal reattach disabled to avoid it. Let me know if it will be helpful and I'll re-enable reattach!
Same as
Yes it would be very helpful I spent 90 mins yesterday trying to reproduce to no avail. If you could enable trace logging too in case you repro, that might give the insight we need
We should review the code around terminal adoption of orphan processes, I suspect the issue is that it's not transactional.
it appears we're only doing an orphan check on terminals that are in the workspace as set in the map
I think somewhere all unadopted processes get taken by some window? Might not be remembering right though.
If you see this again after lands, please enable trace logging and get the output channel logs for Pty Host and Window.
I was seeing this previously on occasion but haven't seen it over the last week so marking as verified
+1 on no longer seeing it since re-enabling re-attach a few weeks ago.
Just saw this again. The incorrect re-attach occurred on 1 July and I only noticed it today. Pty logs: Window logs
This seemed for a while like it'd stopped happening, but just ran into it again: In my case I'd just reloaded a single window.
Just had this happen again, but once again I didn't have trace logging on. I'll try to leave it turned on for next time. Pty Host logs: Window logs:
Could the needed log statement to troubleshoot this on the terminal side be converted to an log. That might help track down this bug sooner.
they're actually warnings already so they should show up:
Just ran into this again. I have the same terminal restored in two distinct windows. I ran into this after restarting to update Insiders on macOS (I had 6 folders opened). The Pty Host log contains the following: https://user- Maybe might know if there's a way to easily simulate a restart caused by an update. Alternatively, maybe you can try changing a setting like which shows the restart prompt. I think this also leads to the terminals attaching incorrectly.
Might be related to (maybe not as that's remote only?)
this is a little confusing to me. No reconnect is meant to happen on restart, when updating node-pty gets replaced so it can't be running, all processes are torn down and the pty host shuts down with the main process. Did you see this? !
Changing this to always return isOrphan = true: I can get it to reconnect which is meant to be prevented by one of my other changes.
It's a little suspicious that the entry doesn't get deleted: That determines here which can bypass the orphan check:
I can confirm that within the last two days (both before and after the upgrade to 1.70.0) it has happened to me both on window reload and on full VSCode restart.
When I see this it also happen on restart.
do you see the history restored message when it happens on restart?
Yes, I see this every time when restarting to install a new version (Gear Restart to Update) or when changing the setting : <img width="473" alt="image" src="https://user-"
I'm 99.9% certain the answer is yes, but I will make sure to notice the next time it happens.
Ok, I figured this out. What a journey! Here is the fairly reliable repro: Clear state - Given 2 folders and Open folders and and close all terminals File Exit Setup for the process revive - Window : Open 3 terminals and type "a", "b", "c" into them respectively, this helps identify them to ensure they're in the correct order later Window : Open 3 terminals and type "d", "e", "f" into them respectively File Exit Process revive - Window and should revive the processes and have all terminals in the correct order they were created (this works) Process reconnect Reload window and window at the same time Window and should revive the processes and have all terminals in the correct order they were created :bug: Note that this is a timing issue and has a chance to not reproduce the problem. This is what is meant to happen when exiting and restarting the pty host process. Terminal processes are revived (aka. re-created) and their actual pty IDs for this pty host process are mapped to, starting at 1. Notice below how the new IDs start from 1, they just represent the order they are created in which shouldn't matter when reviving. After that, when reloading windows, terminal processes do not get revived but reconnected to. So an mapping is expected: What is happening and what is causing this bug as well as a related issue[^1] is that the revived pty ID is cached, so if reloading happens to use a that is mapped to a different pty ID in , it will reconnect to that one instead: The above results in: Then on reload the pty ID mapping occurs instead of being undefined, which causes a reconnect_ to the wrong pty. So in the above they get re-mapped, shuffling the order within a window and potentially connecting to a different window's ptys: ! [^1]: The folder's terminals may not get restored at with the warning "Couldn't get layout info, a terminal was probably disconnected" in the pty host output channel. This started happening due to one of the previous workarounds to prevent 2 windows attaching to the same pty.
Wow. Nice detective work! Thanks, looking forward to the fix.
Reported here
I actually saw it again once earlier this week too. It does seem to happen significantly less often than it used to.
I just ran into this again today. After a restart due to an update, I got a terminal from a folder showing up by itself in folder . Here's the only relevant content I found in my logs:
I hit this today. Moving this forward to January 2023, since it probably was just lost in the queries by being assigned to August 2022.
I've hit this once per day for the past several days. It seems to be occurring more frequently again.
This would probably be addressed if terminals moved into utility process and there was a message port per terminal:
Using the new pty host trace logging, this is what happens on a reload with a single terminal that will be reconnected, with the environment parts truncated:
I believe this is now fixed as a part of I'm still not able to reproduce but the current theory is that the async isOrphan check that was removed in the PR was not only delaying reconnection by 4 seconds, but also causing a race where the wrong window could adopt it. Instead we no longer check whether it's an orphan and trust the saved workplace state to be correct.
Thanks for following up
I haven't seen this in a long time. Not sure whether there is anything that can be done to verify it.
I just ran into this now: had ~4 windows open: Window 1 is vscode-pull-request-github2 : terminals cwd were all in the workspace Window 2 is vscode-pull-request-github: terminals cwd were all in the workspace Window 3 is repo1: 2 terminals, both of which had a cwd outside the workspace Window 4 is vscode: terminals cwd were all in the workspace VS Code reattach: Window 1's terminals are correct Window 2 has reattached to one of Window 3's terminals and has lost it's original terminal Window 3's terminals are correct Window 4's terminals are correct. Pty logs from Window 2:
thanks for the info! Looking into it
I spent a few hours looking into this, here are my findings: This warning in the logs is common across recent failures: , I tried and tried but could not reproduce this on Insiders or OSS I'm adding more verbose logs to the info log level that gives me the old/new pty id mapping as well as dumping a bunch of info when the above error happens I looked into whether should be correct and while I found it could cause issues when the pty host restarts (), it seems like it should work after a restart I could the cwd being outside the workspace would make a difference as we don't even take that into account when reviving the proc () The management of would be a lot simpler if we moved the id to being a guid instead of a number, but that would be a shame as we then need to send the guid along the wire for pretty much every request to the pty host I looked into possible race conditions where could get stale/invalid values. Both a thorough review of the code and injecting timeouts (random, differing by window) into important calls didn't cause problems Current plan is to wait for to merge and await a repro with these logs present, then analyze them. I'll also likely be continuing to fiddle with terminal reconnection in debt week to improve perf further and reduce redundancies.
I'll keep an eye out for this and try to maintain a setup similar that one that I just saw it with, but I have to say, this has gotten so much better. I almost never see it.
I tried to repeat my setup before updating, and it did happen again. Setup: Window 1 is vscode-pull-request-github2 : terminal cwd is outside the workspace and on a different drive (C vs D) Window 2 is vscode-pull-request-github: terminals cwd were in the workspace Window 3 is repo1: terminal cws was in the workspace Window 4 is vscode: terminals cwd were all in the workspace After update: Window 1 is vscode-pull-request-github2 : has a new terminal Window 2 is vscode-pull-request-github: correct Window 3 is repo1: has attached to Window 2's terminal and now they share the same terminal Window 4 is vscode: correct Logs:
Thanks it seems there's some inconsistency with the layout info and the revived procs, so I suspect this silently error swallowing now: Added logs for that here: , I'll merge for July so you might not be able to test for a week but when you do please also grab the Terminal output log as this is renderer side.
Cross post
With logs in , I was able to reproduce the problem! ! The repro is very complicated, it is essentially trying to get into a state where 2+ windows have "old pty ids" that conflict with one another, and then increasing the latency of the pty host in order to force the race condition to show itself. these settings: default log level to trace all windows window 1 (W1) with folder A 1: Open 2 terminals 1: Close window 1: Open window 1: Open pty host log, you should see this: window 2 (W2) with folder B 2: Open 2 terminals 1: Close window 2: Close window VS Code (W2 should open) 2: Open pty host log, you should something like this: 2: Close window an external terminal and type another external terminal and type the commands in both terminals in quick succession 1|W2: Open pty host log, you should see something like this: The terminal with end up attaching to the wrong pty. The fix for this is simple, just add workspace ID as part of the key of the old id, so becomes . This should make conflicts impossible to occur.

if (this._preLaunchInputQueue.length > 0 && this._process) { // Send any queued data that's waiting <del> newProcess.input(this._preLaunchInputQueue.join('')); </del> <ins> newProcess!.input(this._preLaunchInputQueue.join('')); </ins> this._preLaunchInputQueue.length = 0; } }),


Question:
I just reloaded a window with my repo open, and it attached to a terminal which is already open in my repo, so now this terminal is open in two windows: ! The right window is the window that originally owned this terminal One thing about this terminal is that its cwd is some other folder outside of both workspaces, if that matters.
I reloaded the left window again, and it reattached to the correct terminal. !
Just so you know, this happens pretty often. I just reloaded a window and got some random terminal from another window. Let me know if I can collect any other info
Also hit this, I believe it was after restarting insiders for an update. !
I was able to repro once out of many attempts. I wonder if there's a command to reload all windows to simulate what happens on update? Maybe then I'd see it?
exiting the application (cmd+q) and reopening it is essentially what happens on update
Something similar just happened with the most recent insiders update, but now the terminals aren't synced, it's just that the working directory of one window's terminal is set to the other window's root instead of it's own. <img width="1440" alt="image" src="https://user-"
Happened again, accidentally ran a destructive command in the wrong directory :( cc is there any logging or something I can enable to help you get to the bottom of this?
I spent awhile investigating. I don't understand what could be going on here because we store and reconnect to terminals according to the workspaceId. said that he thinks it's a race condition. Setting log level to trace and toggling the shared process would help when it reproes
Today I had something new happen: had 3 VS Code windows open. reloaded window 1. 1 now shares a terminal with window 3! Totally different workspaces. No other windows were reloaded. No windows were closed. Is there a way I can disable terminal reconnect for local windows? I've also run destructive commands when this happens and I don't want to risk it.
Yep, it's not working atm for remote terminals, so:
Hello everyone, there is any plan to try to fix it in the nearest milestone?
This code that we for transferring terminals via dnd between windows looks suspicious
Has anyone seen this in awhile? I cannot reproduce
I don't remember seeing it recently
Okay pls reopen if you see it again and I'll be happy to debug with anyone that can reproduce it
Sorry, I cursed myself because this happened again today but I probably won't have consistent repro steps. I reloaded the window with my vscode workspace and got a terminal from this extension sample which is also open in another window, although the terminal panel had not been made visible in that other window's session yet. I reloaded the window several more times and always got the right terminal after that. <img width="1049" alt="image" src="https://user-"
we don't create a terminal until you open the panel, so what do you mean by the terminal had not been made visible yet?
In case it is important to the issue, I'm just saying that the drop-on-document terminal that was wrongly attached to the vscode window hadn't yet been attached to the drop-on-document window, because it was from some earlier session.
I also used to see this periodically but I've had terminal reattach disabled to avoid it. Let me know if it will be helpful and I'll re-enable reattach!
Same as
Yes it would be very helpful I spent 90 mins yesterday trying to reproduce to no avail. If you could enable trace logging too in case you repro, that might give the insight we need
We should review the code around terminal adoption of orphan processes, I suspect the issue is that it's not transactional.
it appears we're only doing an orphan check on terminals that are in the workspace as set in the map
I think somewhere all unadopted processes get taken by some window? Might not be remembering right though.
If you see this again after lands, please enable trace logging and get the output channel logs for Pty Host and Window.
I was seeing this previously on occasion but haven't seen it over the last week so marking as verified
+1 on no longer seeing it since re-enabling re-attach a few weeks ago.
Just saw this again. The incorrect re-attach occurred on 1 July and I only noticed it today. Pty logs: Window logs
This seemed for a while like it'd stopped happening, but just ran into it again: In my case I'd just reloaded a single window.
Just had this happen again, but once again I didn't have trace logging on. I'll try to leave it turned on for next time. Pty Host logs: Window logs:
Could the needed log statement to troubleshoot this on the terminal side be converted to an log. That might help track down this bug sooner.
they're actually warnings already so they should show up:
Just ran into this again. I have the same terminal restored in two distinct windows. I ran into this after restarting to update Insiders on macOS (I had 6 folders opened). The Pty Host log contains the following: https://user- Maybe might know if there's a way to easily simulate a restart caused by an update. Alternatively, maybe you can try changing a setting like which shows the restart prompt. I think this also leads to the terminals attaching incorrectly.
Might be related to (maybe not as that's remote only?)
this is a little confusing to me. No reconnect is meant to happen on restart, when updating node-pty gets replaced so it can't be running, all processes are torn down and the pty host shuts down with the main process. Did you see this? !
Changing this to always return isOrphan = true: I can get it to reconnect which is meant to be prevented by one of my other changes.
It's a little suspicious that the entry doesn't get deleted: That determines here which can bypass the orphan check:
I can confirm that within the last two days (both before and after the upgrade to 1.70.0) it has happened to me both on window reload and on full VSCode restart.
When I see this it also happen on restart.
do you see the history restored message when it happens on restart?
Yes, I see this every time when restarting to install a new version (Gear Restart to Update) or when changing the setting : <img width="473" alt="image" src="https://user-"
I'm 99.9% certain the answer is yes, but I will make sure to notice the next time it happens.
Ok, I figured this out. What a journey! Here is the fairly reliable repro: Clear state - Given 2 folders and Open folders and and close all terminals File Exit Setup for the process revive - Window : Open 3 terminals and type "a", "b", "c" into them respectively, this helps identify them to ensure they're in the correct order later Window : Open 3 terminals and type "d", "e", "f" into them respectively File Exit Process revive - Window and should revive the processes and have all terminals in the correct order they were created (this works) Process reconnect Reload window and window at the same time Window and should revive the processes and have all terminals in the correct order they were created :bug: Note that this is a timing issue and has a chance to not reproduce the problem. This is what is meant to happen when exiting and restarting the pty host process. Terminal processes are revived (aka. re-created) and their actual pty IDs for this pty host process are mapped to, starting at 1. Notice below how the new IDs start from 1, they just represent the order they are created in which shouldn't matter when reviving. After that, when reloading windows, terminal processes do not get revived but reconnected to. So an mapping is expected: What is happening and what is causing this bug as well as a related issue[^1] is that the revived pty ID is cached, so if reloading happens to use a that is mapped to a different pty ID in , it will reconnect to that one instead: The above results in: Then on reload the pty ID mapping occurs instead of being undefined, which causes a reconnect_ to the wrong pty. So in the above they get re-mapped, shuffling the order within a window and potentially connecting to a different window's ptys: ! [^1]: The folder's terminals may not get restored at with the warning "Couldn't get layout info, a terminal was probably disconnected" in the pty host output channel. This started happening due to one of the previous workarounds to prevent 2 windows attaching to the same pty.
Wow. Nice detective work! Thanks, looking forward to the fix.
Reported here
I actually saw it again once earlier this week too. It does seem to happen significantly less often than it used to.
I just ran into this again today. After a restart due to an update, I got a terminal from a folder showing up by itself in folder . Here's the only relevant content I found in my logs:
I hit this today. Moving this forward to January 2023, since it probably was just lost in the queries by being assigned to August 2022.
I've hit this once per day for the past several days. It seems to be occurring more frequently again.
This would probably be addressed if terminals moved into utility process and there was a message port per terminal:
Using the new pty host trace logging, this is what happens on a reload with a single terminal that will be reconnected, with the environment parts truncated:
I believe this is now fixed as a part of I'm still not able to reproduce but the current theory is that the async isOrphan check that was removed in the PR was not only delaying reconnection by 4 seconds, but also causing a race where the wrong window could adopt it. Instead we no longer check whether it's an orphan and trust the saved workplace state to be correct.
Thanks for following up
I haven't seen this in a long time. Not sure whether there is anything that can be done to verify it.
I just ran into this now: had ~4 windows open: Window 1 is vscode-pull-request-github2 : terminals cwd were all in the workspace Window 2 is vscode-pull-request-github: terminals cwd were all in the workspace Window 3 is repo1: 2 terminals, both of which had a cwd outside the workspace Window 4 is vscode: terminals cwd were all in the workspace VS Code reattach: Window 1's terminals are correct Window 2 has reattached to one of Window 3's terminals and has lost it's original terminal Window 3's terminals are correct Window 4's terminals are correct. Pty logs from Window 2:
thanks for the info! Looking into it
I spent a few hours looking into this, here are my findings: This warning in the logs is common across recent failures: , I tried and tried but could not reproduce this on Insiders or OSS I'm adding more verbose logs to the info log level that gives me the old/new pty id mapping as well as dumping a bunch of info when the above error happens I looked into whether should be correct and while I found it could cause issues when the pty host restarts (), it seems like it should work after a restart I could the cwd being outside the workspace would make a difference as we don't even take that into account when reviving the proc () The management of would be a lot simpler if we moved the id to being a guid instead of a number, but that would be a shame as we then need to send the guid along the wire for pretty much every request to the pty host I looked into possible race conditions where could get stale/invalid values. Both a thorough review of the code and injecting timeouts (random, differing by window) into important calls didn't cause problems Current plan is to wait for to merge and await a repro with these logs present, then analyze them. I'll also likely be continuing to fiddle with terminal reconnection in debt week to improve perf further and reduce redundancies.
I'll keep an eye out for this and try to maintain a setup similar that one that I just saw it with, but I have to say, this has gotten so much better. I almost never see it.
I tried to repeat my setup before updating, and it did happen again. Setup: Window 1 is vscode-pull-request-github2 : terminal cwd is outside the workspace and on a different drive (C vs D) Window 2 is vscode-pull-request-github: terminals cwd were in the workspace Window 3 is repo1: terminal cws was in the workspace Window 4 is vscode: terminals cwd were all in the workspace After update: Window 1 is vscode-pull-request-github2 : has a new terminal Window 2 is vscode-pull-request-github: correct Window 3 is repo1: has attached to Window 2's terminal and now they share the same terminal Window 4 is vscode: correct Logs:
Thanks it seems there's some inconsistency with the layout info and the revived procs, so I suspect this silently error swallowing now: Added logs for that here: , I'll merge for July so you might not be able to test for a week but when you do please also grab the Terminal output log as this is renderer side.
Cross post
With logs in , I was able to reproduce the problem! ! The repro is very complicated, it is essentially trying to get into a state where 2+ windows have "old pty ids" that conflict with one another, and then increasing the latency of the pty host in order to force the race condition to show itself. these settings: default log level to trace all windows window 1 (W1) with folder A 1: Open 2 terminals 1: Close window 1: Open window 1: Open pty host log, you should see this: window 2 (W2) with folder B 2: Open 2 terminals 1: Close window 2: Close window VS Code (W2 should open) 2: Open pty host log, you should something like this: 2: Close window an external terminal and type another external terminal and type the commands in both terminals in quick succession 1|W2: Open pty host log, you should see something like this: The terminal with end up attaching to the wrong pty. The fix for this is simple, just add workspace ID as part of the key of the old id, so becomes . This should make conflicts impossible to occur.

private async _expandTerminalInstance(t: ITerminalInstanceLayoutInfoById): Promise<IRawTerminalInstanceLayoutInfo<IProcessDetails | null>> { try { const revivedPtyId = this._revivedPtyIdMap.get(t.terminal)?.newId; <ins> this._revivedPtyIdMap.delete(t.terminal); </ins> const persistentProcessId = revivedPtyId ?? t.terminal; const persistentProcess = this._throwIfNoPty(persistentProcessId); const processDetails = persistentProcess && await this._buildProcessDetails(t.terminal, persistentProcess, revivedPtyId !== undefined);


Question:
The <kbdToggle Size to Content Width</kbdcan only be toggled a few times, before freezing completely. Resizing terminal could reset it. https://user- Does this issue occur when all extensions are disabled?: Yes System info:
please see my explanation on
Thank you for your detailed explanation. I did test on the insider version, the blur seems to decreased with smaller canvas required but this freezing issue still happens all the time. Moreover, the issue is only on Linux so I'm not sure the explanation is quite sufficient to describe this. Let me know if there's anything I missed, thanks again.
when you do this how long as the lines you're working with? ideally, we probably need an upper cap based on the environment's max canvas size (which would need some searching).
It's hard to say when the doesn't work as expected this time. Do you have any idea to get this revealed? https://user-
when the width of the longest line is less than the width of the terminal, as is featured in your gif, toggling the width won't do anything (by design).
thanks for your information, I did some tests again and got some conclusions: in the menu doesn't work, so I recorded with shortcut . IIt also freezes after the second as expected (bottom scrollbar indicates that): https://user- lines hidden when press are affected (still freezes after the second toggle): https://user- number 2 above seems to happen almost every line length: ! Let me know if I can do any more tests to provide more information.
As compared with how this works for windows/mac, linux is broken given the same text content !
This actually is working by design - when you copy and paste, it includes newline line endings that will indicate to the terminal that line isn't wrapped.
based on , it seems like we should go with the min value since we don't want to calculate this per platform/browser, so going with 8000
I started on Windows to try to understand how works. It didn't appear to do anything on Windows. On linux, I can see the toggle happen, but there is no scroll bar.
it will only happen if there are wrapped lines. so increase the line width or resize the terminal to be more narrow.
the scrollbar is very low on linux and i'm not sure why. I'll open an issue for that - separate from this one
Windows !
thanks, i'll make a new issue for that
Now the same thing is happening on linux too. I will leave this for someone else to verify.
Thank you for getting back. I've tested with the insider build but it doesn't work, I've thought it was some sort of thing related to my particular machine, which confuses me these days. So it's good to track that again on a new issue. Most of behavior I have described in I don't spend much time on Windows so didn't test carefully. Let me know if there's anything else I can do.
Because of the way this feature works where it stretches the canvas to the size of the content we are limited by the canvas API. As a compromise I'm going to add a cap to the number of columns the terminal can take up.

DefaultCols = 80, DefaultRows = 30, <del> MaxSupportedCols = 5000, MaxCanvasWidth = 8000 </del> <ins> MaxCanvasWidth = 4096 </ins> } let xtermConstructor: Promise<typeof XTermTerminal> | undefined;


Question:
The <kbdToggle Size to Content Width</kbdcan only be toggled a few times, before freezing completely. Resizing terminal could reset it. https://user- Does this issue occur when all extensions are disabled?: Yes System info:
please see my explanation on
Thank you for your detailed explanation. I did test on the insider version, the blur seems to decreased with smaller canvas required but this freezing issue still happens all the time. Moreover, the issue is only on Linux so I'm not sure the explanation is quite sufficient to describe this. Let me know if there's anything I missed, thanks again.
when you do this how long as the lines you're working with? ideally, we probably need an upper cap based on the environment's max canvas size (which would need some searching).
It's hard to say when the doesn't work as expected this time. Do you have any idea to get this revealed? https://user-
when the width of the longest line is less than the width of the terminal, as is featured in your gif, toggling the width won't do anything (by design).
thanks for your information, I did some tests again and got some conclusions: in the menu doesn't work, so I recorded with shortcut . IIt also freezes after the second as expected (bottom scrollbar indicates that): https://user- lines hidden when press are affected (still freezes after the second toggle): https://user- number 2 above seems to happen almost every line length: ! Let me know if I can do any more tests to provide more information.
As compared with how this works for windows/mac, linux is broken given the same text content !
This actually is working by design - when you copy and paste, it includes newline line endings that will indicate to the terminal that line isn't wrapped.
based on , it seems like we should go with the min value since we don't want to calculate this per platform/browser, so going with 8000
I started on Windows to try to understand how works. It didn't appear to do anything on Windows. On linux, I can see the toggle happen, but there is no scroll bar.
it will only happen if there are wrapped lines. so increase the line width or resize the terminal to be more narrow.
the scrollbar is very low on linux and i'm not sure why. I'll open an issue for that - separate from this one
Windows !
thanks, i'll make a new issue for that
Now the same thing is happening on linux too. I will leave this for someone else to verify.
Thank you for getting back. I've tested with the insider build but it doesn't work, I've thought it was some sort of thing related to my particular machine, which confuses me these days. So it's good to track that again on a new issue. Most of behavior I have described in I don't spend much time on Windows so didn't test carefully. Let me know if there's anything else I can do.
Because of the way this feature works where it stretches the canvas to the size of the content we are limited by the canvas API. As a compromise I'm going to add a cap to the number of columns the terminal can take up.

this._initDimensions(); await this._resize(); } else { <ins> const font = this.xterm ? this.xterm.getFont() : this._configHelper.getFont(dom.getWindow(this.domElement)); const maxColsForTexture = Math.floor(Constants.MaxCanvasWidth / (font.charWidth ?? 20)); </ins> // Fixed columns should be at least xterm.js' regular column count <del> const proposedCols = Math.max(this.maxCols, Math.min(this.xterm.getLongestViewportWrappedLineLength(), Constants.MaxSupportedCols)); </del> <ins> const proposedCols = Math.max(this.maxCols, Math.min(this.xterm.getLongestViewportWrappedLineLength(), maxColsForTexture)); </ins> // Don't switch to fixed dimensions if the content already fits as it makes the scroll // bar look bad being off the edge if (proposedCols > this.xterm.raw.cols) {


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled? Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.61.0 Commit: Date: 2021-10-07T18:11:58.853Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: the Terminal Sample from the vscode-extension-sample repository the a task that reuses a terminal. For example, I used a user task like: On the first run of the task the 'link' text will create a hover link correctly. If you re-run the task so the terminal has 2 (or more) runs of the task in the same terminal then the link will fail to detect correctly. Adding a breakpoint to there appears to be 1 call per execution of the task in the terminal. I think when the terminal is re-used it re-registers the link provider and if two link providers have overlapping links they both seem to fail (which is a known issue but due to this bug all link providers start failing if tasks are run multiple times).
Putting a breakpoint in the registerLinkProvider call for xterm (here ) I see multiple copies of all of the link providers: <img width="574" alt="Screen Shot 2021-10-12 at 9 15 30 AM" src="https://user-"

private _widgetManager: TerminalWidgetManager | undefined; private _processCwd: string | undefined; private _standardLinkProviders: ILinkProvider[] = []; <del> private _standardLinkProvidersDisposables: IDisposable[] = []; </del> <ins> private _linkProvidersDisposables: IDisposable[] = []; </ins> constructor( private _xterm: Terminal,


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled? Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.61.0 Commit: Date: 2021-10-07T18:11:58.853Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: the Terminal Sample from the vscode-extension-sample repository the a task that reuses a terminal. For example, I used a user task like: On the first run of the task the 'link' text will create a hover link correctly. If you re-run the task so the terminal has 2 (or more) runs of the task in the same terminal then the link will fail to detect correctly. Adding a breakpoint to there appears to be 1 call per execution of the task in the terminal. I think when the terminal is re-used it re-registers the link provider and if two link providers have overlapping links they both seem to fail (which is a known issue but due to this bug all link providers start failing if tasks are run multiple times).
Putting a breakpoint in the registerLinkProvider call for xterm (here ) I see multiple copies of all of the link providers: <img width="574" alt="Screen Shot 2021-10-12 at 9 15 30 AM" src="https://user-"

this._processCwd = processCwd; } <ins> private _clearLinkProviders(): void { dispose(this._linkProvidersDisposables); this._linkProvidersDisposables = []; } </ins> private _registerStandardLinkProviders(): void { <del> dispose(this._standardLinkProvidersDisposables); this._standardLinkProvidersDisposables = []; </del> for (const p of this._standardLinkProviders) { <del> this._standardLinkProvidersDisposables.push(this._xterm.registerLinkProvider(p)); </del> <ins> this._linkProvidersDisposables.push(this._xterm.registerLinkProvider(p)); </ins> } } registerExternalLinkProvider(instance: ITerminalInstance, linkProvider: ITerminalExternalLinkProvider): IDisposable { <ins> // Clear and re-register the standard link providers so they are a lower priority that the new one this._clearLinkProviders(); </ins> const wrappedLinkProvider = this._instantiationService.createInstance(TerminalExternalLinkProviderAdapter, this._xterm, instance, linkProvider, this._wrapLinkHandler.bind(this), this._tooltipCallback.bind(this)); const newLinkProvider = this._xterm.registerLinkProvider(wrappedLinkProvider); <del> // Re-register the standard link providers so they are a lower priority that the new one </del> <ins> this._linkProvidersDisposables.push(newLinkProvider); </ins> this._registerStandardLinkProviders(); return newLinkProvider; }