Code change:
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.

Related discussion:
text: 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