Vscode: Running Code should open a new instance, not activate a currently opened one

[Tyriar]

Ubuntu 12.04, vscode 0.10.1

Currently when you run Code 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 Code 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:

1. Code (open instance of vscode)
2. Code

Expected:
A new instance of vscode is opened

Actual:
The current instance of vscode is activated

[montogeek]

+1

[ntotten]

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.

[bpasero]

You can use the command line option -n to force open a new instance.

[ygorlazaro]

This is good. But there's no way to make it a default option?

[bpasero]

Fair, I can see about an option.

[dmccaffery]

:+1: for multiple instances, but I wanted to provide this workaround in the meantime:

# linux (assuming you symlinked already)
code () { /usr/local/bin/code -n $* }

# osx
code () { VSCODE_CWD="$PWD" open -n -b "com.microsoft.VSCode" --args $* }

[bpasero]

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.

[montogeek]

new_instance?

[bpasero]

Our settings typically follow this pattern window.reopenFolders for example.

[Tyriar]

window.launchNewInstance, window.alwaysLaunchNewInstance?

[bpasero]

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 window.noArgsLaunchNewInstance but its ugly.

[Tyriar]

Do/can the settings have descriptions to go along with them? Adding noArgs to the start kind of feels like adding byDefault, which is implied.

[bpasero]

Oh yeah:

[ericwj]

When I select _File_ | _Preferences_ | _User Settings_, type "window.openFilesInNewWindow": true and press Ctrl+Space it'll show a tooltip "true: Default value".

However, on Windows 10.0.10586.36 in Code 0.10.6, typing code . 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 "window.openInNewWindow" 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. code . 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, code --help nor code -n . won't do anything while an instance of code is already open.
code --help will not show help but reopen code with the folder that was open before closing it, if no instance of code is open.
code -n . will not open the current folder, but open code with a blank file Untitled-1, 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?

C:\> where code
C:\Program Files (x86)\Microsoft VS Code\bin\code.cmd
C:\Program Files (x86)\Microsoft VS Code\bin\code.js

C:\> "\Program Files (x86)\Microsoft VS Code\code.exe" .
C:\> REM Code opens the C:\ folder correctly. It'll show the prompt again, but have a newline after it which is weird. I can type however.

C:\> PATH 
(...);C:\Program Files\nodejs\;C:\Program Files (x86)\Microsoft VS Code\bin;(...)

code.cmd is:

@echo off
setlocal
set ATOM_SHELL_INTERNAL_RUN_AS_NODE=1
"%~dp0..\\Code.exe" "%~dp0code.js" %*
endlocal

code.js is:

delete process.env['ATOM_SHELL_INTERNAL_RUN_AS_NODE'];
require('child_process').spawn(require('path').resolve(__dirname, '..', 'Code.exe'), process.argv.slice(2), { detached: true, stdio: 'ignore' });
process.exit(0);

HKEY_CLASSES_ROOT\VSCode\shell\open\command\(Default) is: "C:\Program Files (x86)\Microsoft VS Code\Code.exe" "%1"

[bpasero]

@ericwj The setting to force reopen files in new windows or not is called window.openFilesInNewWindow and was renamed because it only impacts files and not folders.

From the command line you can use -r to force reuse the last instance or -n 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 code .
• cd into a folder inside the home directory and run code .

You should find 2 instances of code running.

[ericwj]

Assume I'm in C:\Program Files (x86)\Microsoft VS Code 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 .bincode.cmd which starts .code.exe with .bincode.js as the first argument, which starts .code.exe. That's too many steps to just do .code.exe %* which is what the registry sais should happen. If I edit code.cmd to do just that, all is fine.

So I suspect perhaps code.cmd and/or code.js 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.

[ericwj]

Although running code.exe --help doesn't do anything still apart from showing a new prompt with a newline after it.

code.exe -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.

[bpasero]

@ericwj 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 code.cmd/code.js recently though.

[bpasero]

Btw be careful with "code.exe" within the directory of installation, that one might be the code.exe from the installation which is not the same code.cmd we put on the path. hence my comment about PLEASE try it from the home dir.

[ericwj]

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 code.cmd and code.js that I reported correct for the latest (few) version(s) of VS Code?

Note that the registry key I mentioned refers to code.exe within the directory of installation, Code.cmd uses %~dp0..\\code.exe and code.js uses resolve(__dirname, '..', 'Code.exe'). If that code.exe 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 code.exe 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.

[Spown]

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.

[Tyriar]

@Spown nice find, an alternative to that is shift+click.

[Tyriar]

Running code -n . 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 -n consistently opened a new window it would solve my issue as I could use alias to force it:

alias code='code -n'

The middle click thing on Windows would be nice to have though.

[hashhar]

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.

[Tyriar]

@hashhar yeah, I would only expect -n to do something different when opening a folder that is already open.

[hashhar]

@Tyriar I meant that, even using -n doesn't work.

Try this:

code .
code -n .

Expected results are a new instance opening. But it simply transfers focus to the running instance.

[Tyriar]

@hashhar I was agreeing with you :smiley: I think that is the only thing -n is supposed to do but it doesn't seem to work.

[hashhar]

This seems a little trivial to fix. Could you point me to the file that handles the command line arguments?

[Tyriar]

@hashhar it may be harder than you think due to the process management/sharing involved. Here are some relevant files:

• CLI: https://github.com/Microsoft/vscode/blob/master/src/vs/code/node/cli.ts
• Electron main: https://github.com/Microsoft/vscode/blob/master/src/vs/code/electron-main/main.ts

[chuckries]

+1 for middle click in windows should open new instance.

[Tyriar]

Another case that changing this would fix: win+shift+(launcher number) on Ubuntu and Windows.

[bpasero]

For people that expect "code -n" to open the same folder in 2 windows, we DO NOT support opening the same folder in multiple windows yet.

@Tyriar can you update your issue if you meant something else than https://github.com/Microsoft/vscode/issues/2686 ? If not, I would close as duplicate.

[Tyriar]

@bpasero 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 (code/code -n) should open a new window with no folder opened (the same as ctrl+shift+n).
  
  
  
  • Note: This is different to what window.reopenFolders 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 "window.reopenFolders": false, 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.

[bpasero]

code -n should always open an empty window, does it not?

[calrsom]

+1 For taskbar interactions (middle-click, and shift-click) to open a new window.

[Tyriar]

@bpasero yes forcing the call to use code -n fixes this issue, for Linux specifically you can workaround this by changing the Exec line in /usr/share/applications/code.desktop to:

Exec=/usr/share/code/code -n %U

Personally I think this is how the CLI should work by default, unless -r was used or it was the same folder (#2686). If not, we could make the Windows shortcut use -n too like in the Linux workaround.

[Tyriar]

@joaomoreno is it possible to change the Windows shortcut to use -n so that shift+click and middle click work on the taskbar?

[bpasero]

@Tyriar no, requires an Electron update and is already being taken care of in this PR: https://github.com/Microsoft/vscode/pull/15407

[Tyriar]

@bpasero since making that comment I've found just adding -n 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.

[bpasero]

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.

[Tyriar]

I think I found what we need for it to work for Linux without changing default behavior: using [NewWindow Shortcut Group] as the shortcut group. I'll check this out soon. (found reading this https://forum.sublimetext.com/t/launching-sublime-from-unity/2904/6 )

[Tyriar]

That didn't seem to work.

I think I'll create a new CLI arg that forces -n only when the main process already has a window.

[bpasero]

@Tyriar 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 👍

[Tyriar]

I'll see if there's time to fit this in for Jan.

[Tyriar]

I pushed the new CLI arg --new-window-if-not-first 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).

[bpasero]

@Tyriar 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 Code.exe without arguments. There is no way for us to detect this case unfortunately, so we still need the Electron update as well as https://github.com/Microsoft/vscode/issues/15407 to land to get it.

[Tyriar]

Makes sense :+1:

[mosajjal]

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.

[Tyriar]

@mosajjal that's by design, there is only 1 Electron main process and all VS Code windows inherit it.

[mosajjal]

@Tyriar 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.

[mikelward]

+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.

[mosajjal]

it works ! Thanks :-)

[fadeevab]

Should this issue be closed? :)

[Spown]

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).

[mosajjal]

no it should remain open. I'd REALLY like a solution for this. @mikelward's 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

[mikelward]

@mosajjal I'm not saying that's the solution, I'm saying that's the steps to reproduce/desired behavior!

[mosajjal]

@mikelward I know. I edited my comment to point out that's not the solution. Looked a bit confusing

[necrifede]

To meet my requirement I executed using sudo option on ubuntu.

$ sudo code . --user-data-dir=../alternative_folder

for now is enough for me. of course I should dismiss the warning message about running as 'root'

[northeastsquare]

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/x86_64-linux-gnu/libxcb.so.1
https://github.com/Microsoft/vscode/issues/3451

[mikemol]

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.

[spiralsam]

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:

1. The Code installer places what looked like dozens+ of Windows registry entries pointing to "Code.exe" 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.

2. Even if (1) were feasible, this doesn't change the behavior of the Windows taskbar, which executes Code.exe (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 window.open* features are handy conveniences that are fun to have, but they miss the broader picture. Again, only speaking for myself.

[cparker4486]

@bpasero 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.

[bpasero]

I am thinking about 2 changes to make this easier:

1) introduce a new setting window.openWithoutArgumentsInNewWindow
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 window.openFilesInNewWindow: default on Linux and Windows
The default option was never really supported for window.openFilesInNewWindow 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 off 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.

[mikelward]

My use case is code .. Sounds like the second option would help there?

Would -n become equivalent to setting the first option? (If it defaults to off on Mac, keeping the flag might make sense.)

[bpasero]

@mikelward as for opening the same folder in multiple windows, that one is not handled with my proposed change. We have https://github.com/Microsoft/vscode/issues/2686 specifically for that case.

I did not touch the flags -n and -r to force a new window or force to reuse a window, they remain as before.

[bpasero]

Closing as per https://github.com/Microsoft/vscode/issues/48#issuecomment-371556991 via https://github.com/Microsoft/vscode/pull/45322