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]

👍 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 .\bin\code.cmd which starts .\code.exe with .\bin\code.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.

[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
#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 #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 #48 (comment) via #45322