Allow to open a workspace without restoring any state

[vtimbuc]

• VSCode Version: 1.10.2
• OS Version: OS X 10.11.6

Is it possible to init the code editor from terminal code . with a new session?
code . -n doesn't work, it still remembers the last files and project tree I had open.

[bpasero]

@vtimbuc code -n should work but since you tell Code to open the current folder (via .), it will restore the session. So no, there is no way for a clean session when opening a specific folder currently.

[vtimbuc]

@bpasero Yeah, an option to start a clean project session would be great. Could you point me where the session is stored on OS X, I could set that folder to read-only as a temporary solution. Thanks

[bpasero]

@vtimbuc that will not be possible I fear.

[jtlindsey]

I have this issue in Linux too. No matter what i do, if i open via the terminal with code . in my project directory. The previous session is restored.

I noticed other issues with the same problem reported like #41039 and #42062 that were autoclosed.

"window.restoreWindows": "none" is still not effective when opening from the terminal.

Is there a fix for this?

What makes this a feature-request (looking at label on this issue) rather than a bug? The feature is there. It just doesn't work from the command line.

Also posted on stackoverflow looking for resolution or work around.

[fonnesbeck]

Actually, this occurs for me when opening VSCode from the dock in macOS. I created a screencast here that shows the behavior, and I open my preferences at the end to show that restoreWindows is none.

I would definitely call this a bug, and not a feature request. If you turn off window restore, it should be off, regardless of how you open the app.

[mjwsteenbergen]

On Windows, the same behaviour happens. Even running:
"C:\Program Files\Microsoft VS Code\Code.exe" -n
will not start a clean session for me.

Even if this were working, I would expect the "window.restoreWindows": "none" to override whatever rule exists.

This really hampers productivity, as opening a random file on disk will open the file together with the previous workspace I was working in.

[escamoteur]

Same when open code from the Context Menu in Window. I would expect in that case that a new clean instance and not two Windows of which one shows the last session is opened.

[mklemarczyk]

Hi, this issue is still valid for clean installation of Visual Studio Code in version 1.22.2.
Can you estimate when it will be fixed?

I'm starting the app from Menu Start in Windows 10.

[Dyoung0606]

I'm still seeing this in 1.25.1. Are there any plans to implement this? Or, at least, document a workaround? Even letting us know where the session information is stored would be handy. (As mentioned by @vtimbuc above).

Thanks.

[CaerphillyMediaLtd]

Hi,

"window.restoreWindows": "none"

Still rarely works for me on the latest build. It just opens the last folder. Sometimes it randomly does work though.

On Arch Linux, latest VS build.

[fonnesbeck]

Any progress on this? If restoreWindows is set to none, then there should be no windows restored, irrespective of how VSCode is opened.

[kanlukasz]

I have the same problem.

"workbench.editor.restoreViewState": false

"files.hotExit": "off"

"window.restoreWindows": "none"

and when i reopen folder ( CTRL+K + O ), still all files are open

Please fix it

[mklemarczyk]

I think that we are missing the option to skip restoring previous session.

• The setting "window.restoreWindows" is applied only if you trigger VS Code restart. It means it closed and reopened it, but the manual close window and start process is not a restart process. This parameter is only when VS Code restart itself (eg. during the update).
• The setting "workbench.editor.restoreViewState" is about behaviour on opening previously closed file. It can restore view of re-opened file. Like put you in the same place where you been last time when file was open.
• The setting "files.hotExit" is almost about sessions but only for not saved files. This feature can save those files internally and restore them when VS Code is started again. It prevents from question do you want to save this file.

Is there any option to disable remembering the last opened session?

[bpasero]

@vtimbuc (and others), is this "just" the restoring of opened editors or really all state we have associated with a window? There is a ton of stuff we store per window on shutdown and restore on the next startup (to give a concrete example: the breakpoints that you set in editors if any).

It would be relatively easy to add a setting to not restore editors, but I am not sure really starting without any state makes a lot of sense.

[vtimbuc]

@bpasero for me an option to clear all state associated with a window would be great. I like to start fresh when I open my editor in the morning. For me an option we could pass when opening from the command line would be enough, such as code . --no-state. Thanks

[bpasero]

Ok updating to reflect the intent. Keep in mind though that this will mean that everything is fresh, e.g. you will get notifications popping up that you previously maybe configured to "Do not show again".

[kanlukasz]

I am of the same opinion as @vtimbuc. A completely fresh start would be really great. I need it too.
The command line option will be better than nothing, but if possible it would be good to see it in the settings (better for Win users).

[ZLevine]

This is a feature I'd love as well—I have really bad ADHD and have VSCode workspaces for different projects that I launch using an Alfred shortcut; when a bunch of files from a previous coding session pop up, it's super distracting and disrupts my workflow. This is really maddening and makes VSCode almost unusable for me. I just made the switch from Sublime Text, which has had this feature for 7+ years. ;)

Can we call this an Accessibility feature request?

[itsxallwater]

This would be quite handy for an extension I'm a partner on.

cc @pschellenbach

For context, the extension allows for remote connectivity and provides some file system knowledge by constructing a workspace that is used to plumb up some essential things. It would be handy to allow the extension to intentionally launch and re-use that workspace to maintain the plumbing, but set aside any previously opened files.

[JoshuaSP]

So currently my workspace has 284 open editors, and will cause vscode to hang. The lack of this feature (and trying to figure out a way around it) has cost me a few hours. Having found this open issue - and no references to where this state is stored in a file (I've deleted a bunch of things but clearly not the correct ones!) - I maybe have to uninstall? Not sure. Anyway I am voicing my strong support for giving this issue attention. Thank you!

[JoshuaSP]

Ok, so if anybody comes by and has the same problem, at least I figured out finally where the state was living. On a Mac I did (and please, kids, don't do this at home unless you truly know what you're doing)

rm -rf ~/Library/Application\ Support/Code/User/workspaceStorage/*
rm -rf ~/Library/Application\ Support/Code/Backups/*

obvs this will kill any other workspace data you have but really the learning her for me was that both of the above directories were involved.

[alanhoff]

Can't we just use the in-memory SQLite storage whenever "window.restoreWindows": "none" is set?

vscode/src/vs/platform/storage/node/storageService.ts

Lines 88 to 91 in c87c95a

	const workspaceStorage = this.createWorkspaceStorage(
	useInMemoryStorage ? SQLiteStorageDatabase.IN_MEMORY_PATH : join(result.path, NativeStorageService.WORKSPACE_STORAGE_NAME),
	result.wasCreated ? StorageHint.STORAGE_DOES_NOT_EXIST : undefined
	);

[fonnesbeck]

Any update on this? Its a 4-year-old usability issue that should be simple to address.

[ghost]

2021, I'll really appreciate if this request is implemented.

[bpasero]

I recently came across this on macOS which I found interesting for a command line option VSCode could also provide:

open --help

Options:
-F  --fresh Launches the app fresh, that is, without restoring windows. Saved persistent state is lost, excluding Untitled documents

As for using in-memory storage for our SQLite DB that hosts all persisted state: this will prevent "most" state to restore, but not all. Extensions can decide to persist state into the storageUri folder where we do not really have control over.

Back to the drawing board: I somehow feel that most people simply do not want to see editors restore in a window. I am wondering if that is true whether we can simplify the request to:

• a command line option to conditionally disable restoring editors and restoring windows
• a new setting to disable restoring editors

With that, you can either configure "window.restoreWindows": "none" + the new setting or get the same conditionally with the new CLI argument.

Thoughts?

[matejdro]

I worked around that issue by deleting editor state on every startup with that script:

for f in ~/.config/"Code - OSS"/User/workspaceStorage/**/*.vscdb
do
    sqlite3 "$f" "DELETE FROM itemTable WHERE key = 'memento/workbench.parts.editor'"
done

Of course files still persist if I close and reopen workspace without rebooting, but it is better than nothing.

[bbugh]

I was having an issue where opening a specific workspace folder was freezing vscode as described here, and since all of the requests for a way to do this through vscode have been closed, I'm assuming it's not going to get added. It was still freezing even with extensions disabled.

JoshuaSP's comment is useful, though it will delete all workspaces. If you search those folders for the project folder you can delete only the directories relevant to it. For example, I used thi:

cd ~/Library/Application\ Support/Code/Backups
rg --files-with-matches "<project-folder>" | rg "^(.*?)/" -or '$1' | sort -u | xargs rm -rf
cd ~/Library/Application\ Support/Code/User/workspaceStorage
rg --files-with-matches "<project-folder>" | rg "^(.*?)/" -or '$1' | sort -u | xargs rm -rf

I was then able to start the workspace without issue, and kept the rest of my workspaces intact.

[NathanielRN]

Also looking for this. Is there a User setting where we can provide "window.onlyAddFilesMatchingThisPatternToQuickOpen: ~/my/dev/env/path" for example?

[starball5]

Related on Stack Overflow:

• Disable ALL session remembering functions of vs code
• How Can I Always Reset My Workplace Settings for Every Time I Quit VS Code?
• How can I open folders in VS Code using Terminal with a fresh UI state?
• How to prevent Visual Studio Code from always reopening the previous files or folders?

[sinedied]

Still stuck on this in 2024, I have a botched saved state that I can't clear up. Why isn't there a simple CLI flag or command to reset all state and data for a given workspace?

[kauz56]

I recently came across this on macOS which I found interesting for a command line option VSCode could also provide:

open --help

Options:
-F  --fresh Launches the app fresh, that is, without restoring windows. Saved persistent state is lost, excluding Untitled documents

As for using in-memory storage for our SQLite DB that hosts all persisted state: this will prevent "most" state to restore, but not all. Extensions can decide to persist state into the storageUri folder where we do not really have control over.

Back to the drawing board: I somehow feel that most people simply do not want to see editors restore in a window. I am wondering if that is true whether we can simplify the request to:

• a command line option to conditionally disable restoring editors and restoring windows
• a new setting to disable restoring editors

With that, you can either configure "window.restoreWindows": "none" + the new setting or get the same conditionally with the new CLI argument.

Thoughts?

@bpasero

To get this going again:

The issue for a lot of users seems to be "window.restoreWindows": "none" isn't working as expected when opening a folder.
If I understand your post above correctly, you're saying it is working as expected and what we actually want is an additional setting window.restoreEditors or similar.

I'm going to make the bold claim that 95%+ of users would probably assume that setting "window.restoreWindows": "none"` would result in the previously opened files not being opened again the next time they open that folder.

Regardless of this being a misunderstanding on the users part or not, if the resulting behaviour isn't what most users would expect from the way the setting is named I would argue this qualifies as a bug.

=> Can we reopen this?

Also, for a possible solution:
I just emptied ~/.config/Code/User/workspaceStorage then chmod 000ed it.
Haven't tested a lot yet, but on first glance this seems to give me the desired behaviour.

Maybe we can just have a a setting that disables storage/restoring entirely?

/remind me in 7 years

[starball5]

What's isn't there a simple CLI flag or command to reset all state and data for a given workspace?

@sinedied What are the effects of clearing the workspaceStorage folder for Visual Studio Code?

[sinedied]

What's isn't there a simple CLI flag or command to reset all state and data for a given workspace?

@sinedied What are the effects of clearing the workspaceStorage folder for Visual Studio Code?

Yes I know I can go through the workspace storage and delete it manually, which is what I did. But it's a pain when you only want to clear it for one project, having to find in hundreds of others (if you're like me).

[kauz56]

@starball5 @sinedied
Let's just hope for a proper solution like I've outlined above.

In the meanwhile, if anyone needs it...
This works on Linux (possibly Mac aswell) for a makeshift -n flag (use at your own discretion):

Put this somewhere in your PATH, where priority is higher than /usr/bin/ (I use ~/.local/bin/code), then chmod +x.
Now code . -n will delete the respective storage folder before starting.

#!/bin/bash
if [[ "$1" == "-n" ]]; then
    folderUri=$(realpath "$2")
    ctime=$(stat -c %i "$folderUri")
    id=$(echo -n "$folderUri$ctime" | md5sum | awk '{print $1}')
    rm -rf ~/.config/Code/User/workspaceStorage/$id
fi
/usr/bin/code $@

Caveat: If you have multiple instances of code open, this won't work until all are closed.
I assume state is looked for in memory first, before checking the storageFolders at all.