Change:
isMacintosh ? nls.localize('openFilesInNewWindowMac', "Controls if files should open in a new window.n- default: files will open in the window with the files' folder open or the last active window unless opened via the Dock or from Findern- on: files will open in a new windown- off: files will open in the window with the files' folder open or the last active windownNote that there can still be cases where this setting is ignored (e.g. when using the -new-window or -reuse-window command line option).") : nls.localize('openFilesInNewWindow', "Controls if files should open in a new window.n- default: files will open in a new window unless picked from within the application (e.g. via the File menu)n- on: files will open in a new windown- off: files will open in the window with the files' folder open or the last active windownNote that there can still be cases where this setting is ignored (e.g. when using the -new-window or -reuse-window command line option).") }, 'window.openFoldersInNewWindow': { 'type': 'string',

Discussion:
Ubuntu 12.04, vscode 0.10.1 Currently when you run if there is an instances already running (or shift clicking the app icon in Windows/Ubuntu) it will activate the currently opened window. This should open a new instance, the same goes for opening a new instance of with a folder as an argument when an instance is already open. It's a very common use case for many developers to have multiple editors with the same folder open. Repro: (open instance of vscode) Expected: A new instance of vscode is opened Actual: The current instance of vscode is activated
+1
Agreed, this is one of the main annoyances of code. I don't know any other editor that behaves the way code does. The default should be new window with an optional flag to reuse if you really want that behavior.
You can use the command line option to force open a new instance.
This is good. But there's no way to make it a default option?
Fair, I can see about an option.
:+1: for multiple instances, but I wanted to provide this workaround in the meantime:
Does someone have an idea how to name this setting? The intent is to control if launching "code" without path arguments will focus the last active instance or open a new, empty instance.
?
Our settings typically follow this pattern for example.
, ?
Well thats good but does not really capture the case that we only do so if you are passing in no arguments. I thought about but its ugly.
Do/can the settings have descriptions to go along with them? Adding to the start kind of feels like adding , which is implied.
Oh yeah: !
When I select File User Settings, type and press it'll show a tooltip ": Default value". However, on Windows 10.0..36 in Code 0.10.6, typing in a folder will do nothing whatsoever. It won't even reactivate (focus) the current instance. I'm not sure when this behavior was introduced. Previously code would happily open multiple instances without any configuration. The setting mentioned above also doesn't seem to exist, but would be a better name for the setting. I don't want to only open files in a new window. should open the current folder regardless of how many instances of code are already open or whether they have folders or individual files open.

In addition, nor won't do anything while an instance of code is already open. will not show help but reopen code with the folder that was open before closing it, if no instance of code is open. will not open the current folder, but open code with a blank file , if no instance of code is open. Right clicking a folder and selecting Open with Code will correctly open that folder regardless of whether an instance of code is open or not. Combined, this means I cannot open more than one instance of code except through File Exporer and I cannot use code from the command prompt in a meaningful way which I used to do a lot. Could this be an upgrade issue? is: is: is:
The setting to force reopen files in new windows or not is called and was renamed because it only impacts files and not folders. From the command line you can use to force reuse the last instance or to force opening a new instance for whatever files or folders you pass in. Could it be that in your case a window is already opened on a specific folder you try to open and it just is not focussed? There is another issue on Windows 10 where Code is not able to order a window from the background to the foreground, which might be related. To make sure things work properly: close all code instances cd into your home directory and run cd into a folder inside the home directory and run You should find 2 instances of code running.
Assume I'm in so is that folder for this comment. Sure I tried with a folder that wasn't open already. I updated my comment while investigating, please reread. I'm convinced there is an issue with the opening of code through the command prompt. It points to .bin which starts . with .bin as the first argument, which starts . That's too many steps to just do . %* which is what the registry sais should happen. If I edit to do just that, all is fine. So I suspect perhaps and/or were left from a previous install as is the path with points to .bin not . and their contents break all command line switches, at least --help and -n don't do anything whatsoever as I confirmed.
Although running --help doesn't do anything still apart from showing a new prompt with a newline after it. -n .

works but also shows a newline after the prompt that appears (cursor is at an empty line at the left window border after) and correctly focuses the same window and brings it to the front when done twice.
not sure why you refer to "--help", we do not support such an argument! If you suspect a bad install, maybe try reinstalling from scratch after uninstall. I do not think we changed the recently though.
Btw be careful with "" within the directory of installation, that one might be the from the installation which is not the same we put on the path. hence my comment about PLEASE try it from the home dir.
I was using code from the command line in a directory that is a git repository somewhere deep in my user profile, if that's good enough. I started searching for the configuration option mentioned above after experiencing problems launching VS Code. Is the content of and that I reported correct for the latest (few) version(s) of VS Code? Note that the registry key I mentioned refers to within the directory of installation, uses and uses . If that isn't the correct one, that's a problem in VS Code. I might reinstall, but most people don't. They install the new version through the prompts provided by when you release a new version. That's what I did this time, too. So if that produces this problem and clean install fixes it, it's a problem in VS Code.
Middle clicking on the icon in the taskbar in Windows10 should normally open a new window also, which is not the case for VSC - it focuses the current running instance. I won't open a new issue, since i'm pretty sure midlle click on the icon is a shortcut for the above described behavior anyway.
nice find, an alternative to that is <kbdshift</kbd+<kbdclick</kbd.
Running twice definitely doesn't open two instances for me, I remember having issues with this in the past as well (did it ever work or am I misunderstanding its purpose?). If consistently opened a new window it would solve my issue as I could use alias to force it: The middle click thing on Windows would be nice to have though.
I was looking into the Backlog issues and this came up. The way I see it, Code only fails to open a new instance if the currently running instance and the new instance both have same target folder.

It works for opening two copies of a single file. Doesn't work for two empty instances. Doesn't work for two directories. The above behaviour is independent of the flags. No flags make any difference in this behaviour.
yeah, I would only expect to do something different when opening a folder that is already open.
I meant that, even using doesn't work. Try this: Expected results are a new instance opening. But it simply transfers focus to the running instance.
I was agreeing with you :smiley: I think that is the only thing is supposed to do but it doesn't seem to work.
This seems a little trivial to fix. Could you point me to the file that handles the command line arguments?
it may be harder than you think due to the process management/sharing involved. Here are some relevant files: CLI: Electron main:
+1 for middle click in windows should open new instance.
Another case that changing this would fix: <kbdwin</kbd+<kbdshift</kbd+(launcher number) on Ubuntu and Windows.
For people that expect "" to open the same folder in 2 windows, we DO NOT support opening the same folder in multiple windows yet. can you update your issue if you meant something else than ? If not, I would close as duplicate.
since code attempts to open the previously opened folder when launching this way it never works. Things that would resolve this issue: Lifting constraint that the same folder cannot be opened in multiple windows of vscode If vscode is currently running with a folder open, launching without a path specified (/) should open a new window with no folder opened (the same as ctrl+shift+n). Note: This is different to what controls, I still want the previously opened folder to open when no instances of vscode are running. Note: Currently multiple windows with no folder open will not open when using this method when , but ctrl+shift+n works fine. The second option is perfectly fine imo and would allow people to use the OS-level shortcuts that work with everything else (win+shift+num, shift+left click). It can also be a stop gap solution until multiple folders can be opened if that's the desired UX.
code -n should always open an empty window, does it not?
+1 For taskbar interactions (middle-click, and shift-click) to open a new window.

yes forcing the call to use fixes this issue, for Linux specifically you can workaround this by changing the line in to: Personally I think this is how the CLI should work by default, unless was used or it was the same folder (). If not, we could make the Windows shortcut use too like in the Linux workaround.
is it possible to change the Windows shortcut to use so that shift+click and middle click work on the taskbar?
no, requires an Electron update and is already being taken care of in this PR:
since making that comment I've found just adding is not enough as it forces a new window on a fresh launch even if hot exit backups are being restored. Always open a new window (unless there are backups) needs to be the default to fix this globally imo.
I see already different behaviour between Sublime (activates last active window) and Atom (opens a new empty window) so it looks like this is another area where we need a setting. As for shift-click support on the launcher, that makes sense to open a new window.
I think I found what we need for it to work for Linux without changing default behavior: using as the shortcut group. I'll check this out soon. (found reading this )
That didn't seem to work. I think I'll create a new CLI arg that forces only when the main process already has a window.
i think that makes sense, we could then actually also use it on Windows without having to update electron. Also, people that want this behaviour from the command line could create an alias that always spawns code with this argument
I'll see if there's time to fit this in for Jan.
I pushed the new CLI arg to master and integrated it into the .desktop file so this is fixed on the Linux side. :fireworks: Still needs to be integrated for Windows (not sure where this happens).
actually on Windows this might be more tricky and cannot be done easily even with that argument, now I just realise. Because by pinning Code to the taskbar, obviously you are pinning the normal without arguments. There is no way for us to detect this case unfortunately, so we still need the Electron update as well as to land to get it.
Makes sense :+1:
I don't know if this is related to the current issue, but when you run Code in a different folder from the command line, it still uses the first instance's environment.

For example if I had two different virtualenvs, If I run Code in the first one, and then open up a new terminal, go to the second venv and run code from there, it still uses the binaries and the environment of the first venv.
that's by design, there is only 1 Electron main process and all VS Code windows inherit it.
isn't there a way to change that? My work as a Python developer is highly dependent on having multiple virtualenvs and running pep8 in them based on their specific PATH. Sublime3 does it pretty well but I like vscode's git integration and debugging tools.
+1 code -n . code -n . Should launch two instances. In practice, I actually need to be able to run vscode in a remote desktop/VNC session and a local desktop session on the same machine, both editing the same folder/project. At the moment, I have to pkill one so I can start the other.
<delit works</del! Thanks :-)
Should this issue be closed? :)
I still would love to have a new, empty VSC instance when I middle-click on the icon in the task panel (win10 and VSC already opened).
no it should remain open. I'd REALLY like a solution for this. solution actually doesn't work.. Is there a general Linux or Windows sandboxing app so we can contain vscode inside it? By sandboxing I mean a wrapper script which doesn't show the parent process to the running one in each window or sth like that
I'm not saying that's the solution, I'm saying that's the steps to reproduce/desired behavior!
I know. I edited my comment to point out that's not the solution. Looked a bit confusing
To meet my requirement I executed using sudo option on ubuntu. for now is enough for me. of course I should dismiss the warning message about running as 'root'
Hack worked vscode works via xrdp in Ubuntu MATE 16.04: make a backup first sudo sed -i 's/BIG-REQUESTS/IG-REQUESTS/' /usr/lib/x8664-linux-
Would having a separate instance permit me to edit a file in one window and have the preview of the file update in the other window?

My use case has me modifying documents in Markdown or whiteboarding in Graphviz, and sharing up the live previews in meetings. That works better if I can share up only the preview, and not the source code.
Speaking only for myself, opening using Code is a great experience. Opening Code is a bad experience (using Windows). No workaround makes it better for various reasons. The "-n" command line is not scalable: Code installer places what looked like dozens+ of Windows registry entries pointing to "" for filetypes and explorer context menu actions. In order to add this as a default option manually, I'd have to edit each one of these to add "-n" as an argument (out of frustration to Code's startup behavior, I began to try to but stopped after realizing there were so many). I also am encouraged edit registry as well as edit the system-wide Code start menu shortcut as Administrator. if (1) were feasible, this doesn't change the behavior of the Windows taskbar, which executes (or maybe an equivalent application execution call (?)) without the "-n" argument. Middle-clicking Code's icon in the Windows taskbar, or using Win+Shift+[n] (where [n] is the place of Code in the taskbar). always activates an active Code window rather than opening a new window. As far as I can tell there is no way to change this. The window.openFilesInNewWindow=on option solves half the problem of opening files from Explorer, but adds the problem of forcing all File-Open commands to open files in new windows (not my own desire), in addition to not solving the "other problem above. Seeing as how this issue is from Nov 2015, I just want to update the issue for this year, 2018, that Windows Notepad still currently has a more sensible application activation experience: *opening the shortcut opens a new window, middle-click taskbar opens new window, and opening files from Explorer opens new windows, and File-Open does not open new windows. Not possible with Code. Opening Code is a primary user interface experience, and the configuration solutions presently don' t address this. I like all the configuration options but here, many new configurations need not be necessary, I would just like to request a single window.openJustActLikeWindows7NotepadCirca2009=true.

All these other features are handy conveniences that are fun to have, but they miss the broader picture. Again, only speaking for myself.
Any chance you could provide the reasoning from the Code team as to why this hasn't been implemented yet? It seems like a highly desired feature and is a behavior that's relatively unique to Code.
I am thinking about 2 changes to make this easier: 1) introduce a new setting This setting would control what happens when you run Code without arguments when another instance is already running. I think on Linux and Windows we should change to opening a separate window and on macOS I would preserve the current behaviour of focussing the last active instance. If someone has pointers to OS UX guidelines in this area, I would appreciate it, but I have the feeling that macOS favours to focus the the running instance over opening a new one. 2) allow on Linux and Windows The option was never really supported for on Linux and Windows, but now it will favour to open a new window for opening files unless the file was opened from within the application (via file menu or file dialog). I will not change this setting though, by default we leave it to because we prefer opening files in the last active instance over opening new windows. Feedback welcome, I think this would cover the scenarios outlined here (starting just code and how code behaves when opening files). The settings name is not ideal but was chosen to be similar to the other 2 settings we already have for files and folders.
My use case is . Sounds like the second option would help there? Would become equivalent to setting the first option? (If it defaults to off on Mac, keeping the flag might make sense.)
as for opening the same folder in multiple windows, that one is not handled with my proposed change. We have specifically for that case. I did not touch the flags and to force a new window or force to reuse a window, they remain as before.
Closing as per via