Vscode: Restore previously opened folders/workspaces when opening a specific folder/workspace

[rajnisheu]

• VSCode Version: 1.7.2 , portable zip
• OS Version: Windows 10

Steps to Reproduce:

1. Open some workspace folders
2. Close Code
3. Open folder from command prompt by typing code .
4. Last open folders and sessions are lost!

Atom has exactly the same issue :)

[bpasero]

Try with "window.reopenFolders": "all"

[rajnisheu]

Did that already.. first thing when I got started with it.

[bpasero]

@rajnisheu so you say it does not work with that setting?

[rajnisheu]

Yes @bpasero

[bpasero]

@rajnisheu I see what is going on. When you instruct Code to explicitly open on a resource (file or folder), we do not restore the windows. So this setting only has an impact when you just launch Code without providing a path.

[rajnisheu]

I am not sure I can make sense of that @bpasero. To me its not at all intuitive to loose my working session.

Its not unusual to right click and use "open file with" command. If Code wasn't open at that time, all working folders and open files are lost.

This is offered by several tools, including likes of Notepad++ which remember sessions.

I would not call it a feature request. Its _fundamental functionality_. If it is, its probably unusable by me till we can have that in. Its no fun loosing working folders and files.

Thanks for looking into it.

[bpasero]

@rajnisheu what do we do about people that expect "code ." to open exactly one folder which is the folder the "." is pointing to? A change like this always means to potentially break expected behaviour for some users. Since the current behaviour is intended, I set this to be a feature request because this is not something that happens by accident.

[rajnisheu]

@bpasero I am not able to comprehend why would someone expect "code ." to forget their session where an explicit setting for "window.reopenFolders": "all" has been set. Is that not what the setting "all", "one" and "none" are about?

For lack of a better example, lets take the case of a browser. If its been set to reopen tabs from last session aka remember last session, and after close, if an html file, say from the desktop, is opened, should the browser loose all tabs?

That would be a disaster for a user.

[bpasero]

@rajnisheu how about you double click on a file in the windows explorer to do some quick edits, would you expect all windows to reopen in that case from your previous session? to take it one step further, what about using VS Code as external editor, e.g. to quickly edit a git commit message, would you still expect all windows to open?

[rajnisheu]

You do make a point @bpasero.

But that's not how I see developers working with editors. Editors are open most times. Its those occasional moments when, for example, Windows comes of a reboot (which it does nearly every week ;) ), and you unwittingly double click a file before making sure that Code is open, that loosing session is disastrous.

If its a quick edit of a Git message, it would most likely be for a project. Editing a message.. and loosing the session! I can tell you working with a reasonable size team, single message edits are always in Git tool directly or even command line.

I can't imagine working with a modern tool where I am likely to loose my project setups, tasks and several open (and sometimes unsaved) files, even accidentally. In the end, if I have set session to be remembered, that's what I would expect. Extra seconds spent for loading is any day far more acceptable than loosing work!

Thanks for the clarification though, you can close this thread if you wish.

[bpasero]

@rajnisheu I took extreme examples, but that is the reason why "code ." behaves like it does today. You are basically instructing VS Code to open the current working directory as folder (because you add the "." to it) in a new window. We distinguish such a way of opening VS Code from just typing "code" where we assume you want to restore your previous session.

Now, wether this behaviour is good or bad is up for discussion and that is why I will leave this issue open and flag it as feature request. I am not saying that our behaviour is good or bad, just saying that it is a result of us interpreting "code ." not as an instruction to restore the full previous session but rather to only open the current folder.

[rajnisheu]

@bpasero its the same behaviour with Code installed and doing a right click "open with" instead of using "code .". Doesn't matter if its right click to open folder or file.

Previous session is lost.

Is that really the expected behaviour?

[bpasero]

Yes, as long as Code is opened on a specific path (either file or folder), we use that as the session over any previous session. At least that is a consistent behavior I would say.

[37Stars]

I agree with rajnisheu. Anytime I reopen Code it should automatically reopen all the files I had open previously. If I double click or use the context menu to open a file, it should also show all the previously opened files in their respective tabs, along with the file I wanted opened. The editor doesn't have to actually load those other files until the user clicks the appropriate tab.

Personally, I never have files open from just a single folder. Multiple files are open from multiple folders across multiple drives.

Notepad++ does it right. I can even use a tab in Notepad++ as a temporary copy/paste buffer. I never have to save the file.

At the VERY least you should make it a setting so those who want Code to work the way Notepad++ does, they have that option.

Great editor. Love the plugins, Love the themes. It won't replace my current editor if it doesn't automatically open all of my last file. This is especially true since Windows 10 WILL reboot after an update if even you have the settings otherwise. That's a different issue altogether.

[rajnisheu]

Thanks @37Stars, several users I know and I abandoned Code and decided to stick to Notepad++ / other IDEs. The other extremely helpful feature in Notepad++ is the ability to save sessions. This means if I have two (or even more) multi tab instances of NP++ open, I can save these and come back to exactly what I was doing including unsaved tabs after the notorious WIN10 update. NP++ does get it right!

[bpasero]

What you want is https://github.com/Microsoft/vscode/issues/207 and not this issue.

[MrChriZ]

As far as I can see "window.reopenFolders": "all" under Linux just doesn't work.
It will reopen one folder but never two.

[phuze]

Thought this was a bug for the longest time. Never understood what the issue was until I accidentally reproduced it yesterday twice in a row, thus the bug report (#50846). Reading through this issue thread, I respectfully disagree with the VS Code team's interpretation. I don't understand what benefit there is in not loading the previous working state regardless?

Can you explain what the benefit is in not loading the previous state, and what lead you to this interpretation of why users would want VS Code to behave this way? It feels very counter-intuitive -- its not what I've come to expect after having used other IDE's -- or really from the Windows environment itself -- it just doesn't feel right.

Why should I need to launch VS Code, to then be able to right-click to open a file in VS Code? I think what makes it most frustrating is that VS Code is left in this "fresh" state and I find myself having to reload my workspace, over and over again. Respectfully -- that's not a feature request -- that's just a broken application.

Maybe that's where our views differ -- to me, a workspace isnt some temporary throw-away thing. It should be there, always -- each and every time this app is opened, regardless of how its opened. I mean, even if i were to open files via CLI, there's a good chance I have that project in my workspace anyways -- why wouldn't I, and why would a user just suddenly want that to disappear?

In such an event, I question the point of the right-click context menu at all. It just seems to me like you're targeting two very different types of users -- there should at the least, be a user-defined setting to control this behavior.

If your goal is to have code window launched via a CLI open in a "fresh" state, then why force that behavior on the right-click context behavior within Windows? Again, it just seems like there would be very distinct use-cases for opening files in both manners (via CLI and via right-click context menu). And if you're goal is to force a fresh state, then that should be an argument to be passed via CLI, not a forced default behavior in a native Windows desktop environment.

At the end of the day, I take solace in now at least knowomg what causes this bug. It's still frustrating as all heck as it goes entirely against my workflow, but now that I know how to avoid it, hopefully I can curse the code gods less frequently :)

[akoessler]

I also disagree with the VS Code team's interpretation. If I set VSCode to open all files again at startup (reopenFolders:all) I also want VSCode to keep them open if a single file is opened.
It should not matter at all if VS Code is started without arguments (e.g. taskbar link) or started with argument (explorer double click on file). And it should not matter if VS Code is already open or still closed when I double click on a file in explorer.

I just try to switch from notepad++ to VS Code and love it so far, love the plugins, the ui and everything, except two issues: startup performance and this bug of loosing the open files! The files are open for a reason and I want to continue work on them. I never open VS Code with a folder, just as a file editor, and I want VS Code to keep that open.

If it is really necessary to keep that behavior, why not add a setting for that? Or solve that problem (e.g. open as git editor) with a commandline switch like notepad++ does to open a single independend instance?

[lautjy]

Extreme disagreement from here too. I've lost unsaved work and sessions thrice within 2 weeks. By sessions I mean opened files and folders. Yes, I can always reopen them, but the tabs represent my last 1-4 weeks of mental context. All of a sudden its all gone! Also I thought this was a bug in VSCode, but it seems, based on @bpasero, that this is a designed feature of some kind.

Steps to repro:

1. Open files in tabs, and assume they will be coming back
2. Close VSCode representing Windows update or any other reason to turn off the computer
3. Open Explorer, navigate to a file associated with VSCode and double click it
4. Feel lost and confused looking at the contents of the opened file. It just caused you to loose all work and context. Also all Unsaved files are lost, if you didn't have the foresight to set a custom setting.

Mitigations:

• Found the secret (to me) setting that at least seems to not destroy my "Unsaved" tabs: "files.hotExit": "onExitAndWindowClose"

I expected the setting "window.restoreWindows": "all" to fix the situation, but it does not - just like bpasero explained above. It seems that the only reason for this horror is to support code . opening a folder? And perhaps for using VSCode as a diffing tool?
Would it not suffice that code-dot opens a new window, AND all of the old stuff? Same with diffing, or maybe use another program for diffs? Because if workflow for diffs is the reason to throw away all user's opened tabs, ... then I'm speechless.

You see this situation is really awful. Any time I have my work context "saved" in VSCode tabs and VSCode is not currently running, clicking on files in Explorer turns into a mine field. If I accidentally missclick or forget this VSCode special behavior, and hit an associated file -> BOOM! Everything is gone. VSCode is untrustworthy in this respect - as we have learnt to trust Sublime Text, Notepad++, and others.

[lautjy]

Testing around I realized why I was so surprised by this behavior. It's the UX flow.
For weeks I've kept VSCode open, dodging windows restarts, on few different machines. During that time VSCode has taught me:

• when VSCode is running
• double click an associated file
• it opens as a new tab nicely next to my other open work in VSCode

After closing VSCode for any reason, the behavior is very different:

• when VSCode is not running
• double click an associated file
• it closes ALL other open tabs (and Unsaved buffers, lest user had set a setting), only that single file is open

Hopefully we could get a setting for "never close user's files" (perhaps should be the default, as surprise closing is disrespectful).
If one would like to hack around this, PR in mind, where should one start looking?

[lautjy]

Came here to complain again.
(Though let it be noted that due to this issue described in this Issue, I've tried to switch to few other editors. Turns out I couldn't let go of VSCode because it is just too good in so many other aspects. Props to you who work on this!)

Issue:
I've been trying to be extra careful to always have VSCode open, so that if I accidentally double click an associated file in Explorer I don't loose all my work context = open tabs. Today I was trying to run a python script, but accidentally forgot to write python in the command which opens the file in an associated editor:

pipenv run src/msgpack_test.py (it should have been pipenv run python src/msgpack_test.py)

I observed two different behaviors:

• if VSCode is open, file opens in a new tab next to all my open work (Good)
• if VSCode is closed, it closes all open tabs and opens just msgpack_test.py (Bad, aka unexpected)

It seems xtronoid complained about this, or something very related, in above issue.

From my POV a setting that says "always open files as tabs in current vscode workspace" would fix everything. I'm aware that situation requires more design, as there are workflows that VSCode supports that are unfamiliar to me.

Based on above explanations by @bpasero, VSCode is now geared to support this workflow:
"user wants to open all files in one directory, and close all tabs in current workspace".
and perhaps also "using VSCode as difftool to open file comparison".

I do agree that difftool started by Git for example should probably open a new window, and not a new tab in current workspace.

So is it possible to enumerate the features & workflows, and design the system to never disappear user's workspace?
It's just quite annoying to keep loosing all my work context - which never happened to me when using Sublime Text.

[jamesdlow]

Found this after trying to add a similar issue. It also seems completely unintuitive to me that when opening code from with a file or folder as an argument the previous session is not restored. If I were to click a new web link and Chrome happened not to be open, I wouldn't expect it to not restore my tabs, and only restore them if I opened it manually first and then clicked a link.

I understand that the Code team may desire to maintain the existing behaviour by default, but would it be so hard to add an option to always restore previous sessions when opening a new file for those of us that do want that behaviour. That's how I've been using TextWrangler for years until I went in search of a new editor with code completion. Code seems to have the best I've tried, but I'd love to see it restore my previous session even when opening a new file or folder as an argument.

[irisshieldsAutogrid]

I have to agree with Rajnisheu as well. Especially now my Mac crashes every day (new Mojave OS sux) and VC is the ONLY app that refuses to restore my session, it's pretty tedious. And "yes", when I open VC to start from a correct close down, I would still not mind it restores the previous session. If I really want to start fresh I tend to open a "new window" instead which then indeed opens a fresh clean slate.

Signed:

• UX Architect -

[edmorley]

Please can this issue be reopened? Even if it's decided that this should not be the default behaviour, it would be great to have an option that let's us override it.

[irisshieldsAutogrid]

Hi @edmorley looks like this is now happening, for me it is restoring previous folders/files now.

[jimjoh]

Problem still exists for me, v 1.31.1 on Win10 and CentOS 7.6, steps to Reproduce:

1. Open some files in Code
2. Close Code
3. Double click on a file from Explorer to open it in Code
4. Last open folders and sessions are lost

[irisshieldsAutogrid]

They are not lost. But when you close your window and then ask VC to open a specific (other) file from Explorer or Finder, it is going to do what you ask of it: open that file and that file alone. This is expected behavior of any software. However if you want to go back to where you were before you can go to "open recent".

This particular thread is about restoring the same files (that were open when you close the app/ window) when opening the same folder/ workspace; and it is doing that now. It is even restoring everything after you closed the computer down improperly (or after a crash). That is why this particular thread is close/ resolved.

[phuze]

The issue here, is that workspaces are not remembered. I think a few folks here have misspoke and thereby shifted the conversation off topic slighty.

[irisshieldsAutogrid]

Well, again: it is working properly for me. It is remembering my workspace(s) now. But not when I open one specific file like jimjoh describes (which I don't think it should as you ask it to open that specific file)
I'm on Mac though...

[phuze]

I appreciate your opinion, but I think it's clear there are a lot of folks who don't hold your same viewpoint. Personally, I can't logically understand why a workspace should be forgotten because I choose to open a new file without first having VS Code running. However, if VS Code is already running, and I open a new file, my workspace isn't lost. It doesn't make much sense and is simply not consistent, especially within the Windows environment itself --- it's just not expected behaviour. The Microsoft team which maintains this program, has explained that they are aware this happens, and does it intentionally as it is more favourable when using VS Code from a command line. Which is understandable, but I feel that there are more users using VS Code in a desktop environment, than via a CLI. Therefore, I think a reasonable compromise would be to implement such functionality through a user defined option, rather than leaving desktop environment users high and dry.

[jamesdlow]

There definitely seems to be enough support on this thread alone to warrant an option for those of use that would like that behavior. I ended up always running VS Code on startup to make sure I never clear my previous workspace when opening files.

[rajnisheu]

What a way to shoot yourself in the foot. This thread was started in 2016, and 2019 still no sign of solving the issue.
It looks the product core is incapable of doing this. Would be helpful if someone could close the thread.
Three cheers to well thought, friendly tools like Notepad++

[Zyxyx]

Please, please, please... It's driving me crazy.
I try to open VS Code as soon as my computer starts to avoid losing my previous VS Code 'session'... but, yeah, sometimes I forget. And it is so frustrating when it happens. Each time such a waste of time.

As mentioned before by many others, I find it utterly counter intuitive to lose all my open tabs (files) when I open this - otherwise near perfect - editor by double clicking on a file. Other text/code editors do not do that, browsers do not do that when clicking on a link or double clicking a .url file, and many other programs mimic that behavior so why can't we expect VS Code to act the same way ? At least when "window.restoreWindows": "all" is selected (or another option if it makes more sense to you).

We are not asking to change the way it works by default, but to give us the ability to always (!) restore the previous 'session' when opening a file or folder while VS Code is not started yet. In that configuration, if anyone wants to open a clean new VS Code instance/window with no open files, it is pretty easy to do so.

I thought I had to finally add my voice after coming back so many times to this feature request.

[bkarlson]

I could not figure out why VSCode suddenly started losing my workspaces, until I discovered this issue... crazy oversight / bent logic from devs' side. Now I can only try to begin to attempt to remember how many UNSAVED files there were in my now prematurely closed workspaces, and trying to recover them by hand. Crazy monkey wrench in the middle of a sprint.

[surajmandalcell]

It's strange to see this annoying issue still not being seen as an 'issue' by devs smh

[VigiFyre]

At least once every week I lose my entire work context and have to find and open everything again only because I've committed a cardinal sin of forgetting to manually open VSC before double-clicking a file.

While there's no actual work being lost, so this issue is not really critical, it is still as close to being critical as it gets.
I cannot for the life of me understand how is this still not addressed after 3 years, and why do we not even have a "restore previous hot-exit session" button for cases like that. @bpasero

[aadisriram]

I built something for atom to be able to restore workspace because I was sick of losing all my tabs, I made this associate the state (files, tabs, arrangement etc) to the local commit, so if users moved between commits it would be able to restore their last known workspace state for that hash (even if the hash was amended multiple times, it would be able to track the changes based on mercurial). I'm looking at possibility of doing something similar on VSCode but couldn't find an official API that does a "...deserializeWorkspace(someObject)" like what atom had. Even if VSCode doesn't consider this an issue it would be helpful to know if this functionality exists.

[phuze]

@aadisriram sounds interesting but I'm interested in better understanding what you mean by basing the saved state on 'the local commit'? Would I be correct in assuming that you are assuming that a user associates a single instance of VS Code to a single project? If this is true, I'm not sure I understand how this relates to workspaces in VS Code which can have many projects/repositories in that single workspace. Can you please elaborate?

[lautjy]

.. For what my comments are worth, I've seem to have changed my working habits to somehow match VSCode UX. I now try to open one VSCode instance per code repository. VSCode keeps the state in that folder/repository, and always opens the tabs what I previously had open.

This means I've created one "project" / "context" (just a folder) for main information collecting, main todo lists, random temp scrathcpad stuff, etc. So if I have some thoughts or overall planning, I open that "context" in a separate VSCode instance. Using i3 window manager on Linux helps keeping the instances in a sensible order. On Windows (my previous OS or choice) it would be slightly harder to keep track of which "project" I'm in at what point.

This tends to become a hassle if I need to work over more than 4 contexts (projects), as switching between VSCode instances messes up my focus. Hmm.. maybe color coding the instances would help.

My previous complaints in this thread (similar to what the latest comments here reflect) were due to tyring to use one VSCode instance as the "main" thing. Always trying to open only one VSCode window ever.
I don't know if the UX philosophy of VSCode is clearly stated somewhere - aka what is the right/best/intended way to use VSCode. That might be helpful.

[phuze]

@lautjy Your post convinced me to try this method of working. I have to admit, I do like the idea of having these individual saved states that are restored when opening a project folder. It also inherently resolves something I personally struggle with when using large workspaces, and that's managing the structure tree -- it can get annoying when trying to jump between different projects; i find its much easier to manage when each project is in its own VS Code instance (window).

I'll add that it actually feels like this method of working is how VS Code was intended to be used. By comparison, workspaces (which I'll note is immediately how I started using VS Code), does not feel intuitive (in regards to this issue thread) inside the Windows desktop environment. Which really makes me wonder exactly what Microsoft was trying to achieve with workspaces in the first place? Regardless of Microsoft's opinion that they function as intended, workspaces feel broken and I've decided to abandon that concept of working.

I'll note one important thing for anyone else considering this style of working -- within the Windows environment, I feel that its critical you install VS Code with both options: opening folders and opening files with the "Open with Code" context option. Initially when I installed VS Code, I had only select the context menu option for files. Without the folder option in particular, you'd otherwise have to use the File > Open Folder menu controls every time, which can be annoying.

Lastly, @aadisriram, after having tried this method of working as described by @lautjy, I can confirm that everything you described in your post, already happens in VS Code. Tabs, unsaved files, the order of those tabs, and the state of your file/folder tree is saved and restored when you close and re-open a project.

[aadisriram]

@purplekrayons ah sorry din't mean to confuse, in the world I come from we do stacked commits and often the files I touch in commit 1 are different or a sub/superset of the next commit on the stack. So I had built something into atom that would automatically open up the window state as it was the last time I was on that commit.

Ex: on commit 1 I have files A, B, C open with a 3 pane setup with the file tree open
on commit 2 I have filed C, D open in 1 pane setup with a debugger pane to the right and no file tree

This was useful especially when working with multiple devservers, I was able to checkout a commit on a new devserver and get back my old state that I had last left it on a different machine. I understand this is a very unique usecase but atom let me build this (in a very hacky way I must say) but if vscode had a way to get a saved workspace state that can be restored on demand that might be useful for folks like me, maybe more?

[phuze]

@aadisriram Thanks for the clarification. What your describing is actually something I would also find very useful, at least in the sense that it would allow for saved states across multiple machines, which is something I juggle on a daily basis (home and office desktops and laptops).

[messtory]

My problem was that I somehow deleted my projects.json file in my application support>code>user folder.

I've tried the usual stuff to fix it:

"window.restoreWindows": "all",
"files.hotExit":"onExitAndWindowClose",

When I put that file back, everything worked as expected.

[jaycs1723658]

up

[sparr]

I have just encountered this data loss bug and am rather upset to see that this has been known for four years and not resolved. I rely on my editor being able to recover workspace arrangement and unsaved files/buffers after a crash, power loss, etc. For vscode to intentionally abandon this behavior based on which way it is opened is unfathomable to me. I spent days trying to figure out how I lost some data, then inquiring in support chat rooms about this behavior I "discovered", just to find this issue where I see that this is expected behavior.

[mellevsen]

Lest Microsoft close this ticket for lack of recent activity (which I've noticed is happening increasingly often across a wide array of bug reports), I'd like to add my voice to the crowd of disaffected developers. I had no idea this issue had been identified 4 years ago, and then IGNORED FOR 4 WHOLE YEARS!

It's always been an annoyance with using Code, and I can't count the times I've lost a complicated "workspace" simply because I forgot to open Code on its own before using the "Open with Code" context-menu item in Windows Explorer, or called it up from a command line.

The current behaviour is a massive disruption to workflow, and completely un-intuitive. Whatever happened to the Principle Of Least Surprise?!

So c'mon Microsoft: Admit you got it wrong. Just give us a setting which always restores the previous workspace regardless of opening method. And if you can't do that, a "Restore Previous Workspace" menu item might suffice.

[surajmandalcell]

The problem is worse for mac so I'm now used to closing everything with command+q thanks to vs code. Guess that's what "learning a software" means nowadays...

Also, people might be interested in "Project Dashboard" extension if you have many workspaces to switch between.

[lautjy]

I'll repeat what I wrote few comments above (1 year ago):

Code works well when you always have your workspace in a folder.
So with Code you should have every "context" saved as a folder on your harddisk:

• Programming that new Pytorch model: dev/new_model/
• Keeping notes of things you study: dev/notes/study/
• etc. for every "context" you have.

Then you just CTRL+k o to open a folder, and you select the folder that matches the "context" you need to work on.
You then need to open a window of Code for every context.

The actual state of a "context" (aka folder) is stored in Code/User/workspaceStorage/ (I guess). Hence all your tabs and unsaved data is stored - but it is tied to a folder on the filesystem!

The workflow you (and I previously) are complaining about is how Sublime Text works.
There you have kind of like 1 global context, where all your files, tabs, etc., saved or not, are stored.
Then you just open Sublime and continue work.
With Code you need to open Code, CTRL+k o, select folder, and continue work.

[StephanRoemer]

This is completely ridiculous. I'm using Code on Windows AND on macOS.
On Windows, the session is ALWAYS lost, when calling Code externally (by opening file via explorer).
On macOS the session opens perfectly fine, when opening a file, while Code is closed.
So this is clearly a bug and needs attention and not a discussion on how wrong the users are.

[jimjoh]

This is completely ridiculous...On Windows, the session is ALWAYS lost, when calling Code externally (by opening file via explorer).

I won't argue with that. I agree that if you don't have a folder open VSC should always remember your open files in a default workspace. However, @lautjy's reply is a good (non-obvious) workaround. When he first posted his solution a year ago I ignored it because I didn't think it would work for me since the text files I edit are scattered around my hard drive (not under a single folder). However it does work for my workflow. I created a folder (named WS) that is empty that I just use for my VSC workspace. The folder is empty, it holds no files or folders, but it still allows VSC to magically remember all of my open files.

Now when I open VSC from its shortcut it by default restores my "WS" folder (workspace) files. I.e. it restores all the files I had open last time. If I open VSC by double clicking on a text file all of my open files are lost (i.e. my workspace is lost), but I can easily get them back by going to "File->Open Folder" (CTRL+K CTRL+O) and opening my "WS" folder.

To make it even easier to open my WS folder I use the Favorites Manager extension and have my WS folder saved as a favorite.

[StephanRoemer]

I will check that out, thanks for the heads up. Much appreciated.

Still, the fact that we have to argue about the behavior with the devs is totally ridiculous.
Imagine you would open a link from your email program and the browser would just empty your complete session with all tabs and only load the clicked link. This is totally counter productive.
In the end, such frustrating behaviors will just lead to going back to other applications. Even more if the devs play stubborn. And once again: it IS working on macOS.

[jimjoh]

And once again: it IS working on macOS.

That surprises me since I have the same problem on Windows and Linux. One of these years I'll have to try a Mac. :)

[StephanRoemer]

I double checked, it definitely worked that way. Now that I closed the workspace from Code, it doesn't work anymore sigh.
This really drives me crazy...

[bpasero]

As part of our issue grooming effort this month I am thinking of looking into this. A related issue is https://github.com/microsoft/vscode/issues/14675 which is more specifically around restoring opened editors, but I think a solution should ideally cover both.

Current thinking is to introduce a new setting window.startup for this because imho we cannot break existing behaviour:

• default: behaviour as today, selecting a file or folder to open when VSCode is not running will only open that
• restore: depending on the window.restoreWindows setting, all windows from the previous session will restore first and then the file or folder will be opened. if a file is selected, it will open in the same way as if you had VSCode already running and open it then (i.e. in the last active window or the one that has the folder opened the file is in) and if you pick a folder, it will open a new window or reuse the last active one depending on other settings

To give examples how this would behave:

• double click file to open -> opens in last active window or matching window that has parent folder opened as a new tab alongside all other opened editors
• open folder -> opens a new window for that folder and all the other windows that were open
• git config from a command line (provided that VSCode is configured as git editor) will first restore all your windows and then open the git editor in the last active one (not a separate window)

Thoughts?

[sparr]

Alternate solution proposal: When opening a specific file/folder/workspace, don't discard the previously saved session, just keep it saved and do nothing with it. When closing VSCode and it's time to save the current session for [possible] reopening next time, append them to that saved session. Best of both worlds?

PS: Yes, I know there's a tricky bit here related to figuring out which part of the session to overwrite when doing automatic saves for crash recovery. I have some ideas for that, but it seems like an implementation detail rather than something worth discussing as target behavior.

PPS: It would be even spiffier if there was an interface for tracking and restoring one or more of multiple saved sessions, but that would be a much bigger feature to implement with totally different UX. I chose the simpler and more transparent solution here intentionally.

[joshrivers]

@bpasero I think your proposal sounds solid. It is purely additive and optional and won't make things worse for anyone using the current default behavior. A few questions:

1. Would using vscode on the command line with this setting enabled also reopen the previous session? (I think it should)
2. Do you see any scenarios where, with this option enabled, an unsaved buffer would be lost by restarting my machine or restarting vscode?

[bpasero]

@sparr

Alternate solution proposal: When opening a specific file/folder/workspace, don't discard the previously saved session, just keep it saved and do nothing with it. When closing VSCode and it's time to save the current session for [possible] reopening next time, append them to that saved session. Best of both worlds?

Not sure, I find this a bit hard to understand for the user what happens. I feel my proposal comes close to what browsers support via settings where you can chose to always restore all your previous tabs and windows or not when opening a single link. I feel that users would feel more comfortable with a setting that behaves like I described given this matches what browsers do.

@joshrivers

Would using vscode on the command line with this setting enabled also reopen the previous session

It would actually always restore in any case, not just double click on files or command line, even interactions where a protocol handler is involved (e.g. a link in a browser uses the vscode protocol and triggers to open something inside VSCode. Basically in any case where VSCode is started no matter how, all your previous windows would restore.

Do you see any scenarios where, with this option enabled, an unsaved buffer would be lost by restarting my machine or restarting vscode?

No never. Restoring of unsaved editors is always explicitly handled. Even today already, we forcefully restore all windows and editors that are dirty even when you ask VSCode to just open a single file.

[lautjy]

2 cents:
Sounds like your proposal will solve the gripes we've had in this thread.
Though a new user would first have to hit this behavior, realize what happens (took me a while back then, thought vscode was crashing or something), then look for a solution.

Any ideas about how to make this information easy to find for users?
Maybe one of those small popups that advertise extensions; could advertise this optional setting when user 1st time opens a single file?

[jimjoh]

@bpasero

Current thinking is to introduce a new setting window.startup for this because imho we cannot break existing behaviour:

I think your ideas sound good, but I agree with @lautjy that users will continue to be confused by the existing behavior which I consider broken. Why can't you "break existing behaviour"? Defaults can be changed to be better.

[bpasero]

@jimjoh I think it can cause frustration too if this was the default. For example, you may decide to use VSCode as editor for git commit messages and anytime VSCode opens to show the git editor, suddenly all other windows and editors would restore if it was not running before.

I agree that a nice feature would be to be able to restore windows + editors from previous sessions as a way to get back to the last state even when meanwhile a single editor was opened.

Btw I just checked how browsers do it, and Chrome for example does not seem to put "Continue where you left off" as a default:

[sparr]

Your analogy to browsers is not entirely appropriate. Unless you use extensions to do so, browsers don't save user-entered information when they are shut down (like form fields), so less total and less important information can be lost if a session is lost. Further and far more importantly, browsers have different behavior when they crash, and I think it's getting lost a bit in this conversation that part of this bug is the loss of unsaved data when vscode crashes. If you want to analogize to browsers, you need to provide a different workflow with a prompt to the user to restore their session if the program closed unexpectedly.

I still can't believe we need to argue this. Literally every program/platform/app that I use to enter text can restore my "unsaved" data after the program or computer crashes. Sublime, Atom, VSCode, MS Office, Libreoffice, Google Docs, Evernote... This is a standard feature in even remotely capable text editors for the last ten years. VSCode is the only one that throws this feature away because the user happens to relaunch the program in a specific entirely usual way.

[bpasero]

@sparr I cannot follow your argument. Are you implying that VSCode is loosing unsaved data in any way?

[sparr]

Yes. When VSCode throws away the saved session because you opened a specific target file or folder, that session can include unsaved files/buffers.

Search up-thread for "unsaved" or "buffer" for other people pointing out this failure mode.

Reproduction steps:

1. code
2. File > New
3. type foo into the new file
4. killall electron (obviously do something safer and more specific if you use other electron apps)
5. code /

At this point your "foo" seems to be irretrievably lost. If your step 1 had targeted a specific directory like code /usr/src then you could recover the lost file by doing code /usr/src again, but only if you remember that that's the directory you used to open the instance of code where the lost file was.

[bpasero]

@sparr understood, I forgot about a change we did in March: https://github.com/microsoft/vscode/issues/92467 (cc @aeschli) where we no longer open folders/workspaces that contain dirty files. Fact is, we lost this behaviour for a couple of months and then decided to not bring it back because it resulted in a sudden spawn of tons of windows for users that accumulated dirty files in various folders and workspaces. Our UI solution was then to indicate workspaces with dirty files in the picker with a black dot:

Still, this is NOT data loss. You will always see your recent workspaces in VSCode to navigate to and whenever you navigate back in you will get your dirty files back.

To summarise:

• we used to restore every folder, workspace, empty window that contained dirty files until 1.32 where we lost support for this for folders and workspaces
• in 1.43 we decided to keep this behaviour (empty windows with dirty files still restore because there is no other way of getting your data back)
• we never supported to restore folders, workspaces, empty windows when you ask VSCode to open a specific file or folder (basically what this issue is about)

I feel the original intent of this issue was to restore the windows and editors independent from having files dirty or not. Arguably we could introduce a setting that would only restore those windows with dirty files, but I feel that is not really what people asked for here.

Does that make sense?

[rajnisheu]

@bpasero I am the original poster of the issue, and am glad this is being visited four years on! Better late than.. :)

What you say in https://github.com/microsoft/vscode/issues/15949#issuecomment-724714778 is exactly what I think the behaviour should be.

Most people understand the implication of opting for "Continue where you left off". And that is what VSCode should do. As with the browser, or infact similar tools, if there were 15 windows open, all should restore. If VSCode can handle opening an isolated instance for git diff or git commit, good. But not at the cost of loosing work. In any case there are other possibilities to handle diff or commit as well.

With this feature, and multiline tabs, VSCode will achieve _awesome_ 🥇 and can become a truly mainstream IDE 👍

[sparr]

@bpasero I do not understand how to apply your description to the reproduction steps I provided above. How can I recover my unsaved "foo" file?

[bpasero]

@sparr that depends wether the untitled file is part of a folder/workspace context or an empty window:

• empty window: we always restore that window and file
• folder/workspace: you get the dirty file back once you opened that same folder or workspace (you can use File > Open Recent > More... picker to see all folders/workspaces that have dirty files)

[sparr]

That's amazingly useful and not at all intuitive. Thanks to this advice I've been able to recover three dirty workspaces with unsaved files that I thought were lost.

Sadly the one I most regret losing, the one that brought this bug to my attention, is not represented in that picker. I only wish I'd known to check there when it happened.

[StephanRoemer]

• default: behaviour as today, selecting a file or folder to open when VSCode is not running will only open that
• restore: depending on the window.restoreWindows setting, all windows from the previous session will restore first and then the file or folder will be opened. if a file is selected, it will open in the same way as if you had VSCode already running and open it then (i.e. in the last active window or the one that has the folder opened the file is in) and if you pick a folder, it will open a new window or reuse the last active one depending on other settings

Thoughts?

This is totally how I would expect it to work, huge 👍 !

[bpasero]

I presented this in our UX meeting and think we can push this to insiders for feedback. One discussion was around the name of the setting. The existing proposal was to have a new setting that controls this behaviour, however it might be very confusing given we have window.restoreWindows already.

How would people feel if we added another option to window.restoreWindows to control this? This would mean, you could not chose anything but to restore all windows, but I feel that is the gist of this issue anyway. The sum of options in window.restoreWindows would then be:

• preserve (new): all windows are restored, independent of how VSCode was started
• all: all windows are restored, but not when you start VSCode on a file or folder
• folders: only folders are restored, but not when you start VSCode on a file or folder
• one: only a single window is restored, but not when you start VSCode on a file or folder
• none: no window is ever restored

Thoughts?

[StephanRoemer]

Sounds good to me!

[bpasero]

I have pushed window.restoreWindows: preserve as new choice. all is still the default. We might want to revisit the name of the setting value if we find a more suitable one. This can be tested from tomorrows insider build and then I would appreciate if people could report back how it goes.

One potential feature request I already see is to support --new-window command line flag to enforce opening a single file into a new window even when window.restoreWindows is set to preserve. Currently a file will always open in one of the windows that restore.

[lautjy]

Ah, --new-window would definitely be helpful :+1:
Hard to find which window has opened a file I clicked (hence I use other editors for single files these days).

[Jonatino]

I have pushed window.restoreWindows: preserve as new choice. all is still the default. We might want to revisit the name of the setting value if we find a more suitable one. This can be tested from tomorrows insider build and then I would appreciate if people could report back how it goes.

One potential feature request I already see is to support --new-window command line flag to enforce opening a single file into a new window even when window.restoreWindows is set to preserve. Currently a file will always open in one of the windows that restore.

@bpasero what determines what window the file opens in?

[sparr]

In a perfect world, it would open in the same place that it would have opened if you'd already had vscode running and opened the file from outside the program, which I think depends on whether or not the file is within any existing open workspace.

[bpasero]

@Jonatino yes I think @sparr described it well. The experience of opening a file will be the same independent wether VSCode is running or not. We have some logic that tries to find the best window when opening a file. E.g. ensuring that a file opens in the window where the parent folder is opened in.

[bpasero]

This can now be tested from our insiders release channel: https://code.visualstudio.com/insiders/