Vscode: macOS Mojave: code command line generate duplicate "recently opened" icons in dock

[fourcels]

Issue Type: Bug

$ code 
$ code
$ code

VS Code version: Code 1.28.0 (431ef9da3cf88a7e164f9d33bf62695e07c6c2a9, 2018-10-04T16:40:40.180Z)
OS version: Darwin x64 18.0.0 (10.14)

[bpasero]

This sounds like a OS issue to me and not something VSCode could produce. I have not seen this.

@fourcels does it make a difference if you run "code" from the command line?

[afumagalli]

Just throwing my hat in to say I'm experiencing this too - every time when running code from the command line. It seems that Mojave treats this invocation as a new application instead of recognizing it as already being in the dock. I believe this could be an issue in the code shell script as opening other applications from the command line does not cause this behavior.

Note: this is related to the new "Recent Items" feature of the Dock thus why it only occurs in Mojave

[bpasero]

If someone has ideas...

[afumagalli]

Looked into this a bit deeper. Calling the executable of any application from the terminal while that application is already running will result in the observed behavior, even for stock macOS apps. The solution would seem to be to rewrite code.sh so that it opens VSCode without calling the application executable or hope it gets patched in a future macOS version.

The former should be possible as Sublime Text's similar subl command does not exhibit the behavior.

[chauncey]

Just to add some additional information since I was curious about this one.

With the Mojave 10.14.1 beta release I am not having this problem. I tried a few different things with the Code insider build, 1.29.0-insider.

• With a VS Code window that was invoked from the dock
  
  
  
  • Tried running code-insiders from my home directory
  
  
  • Tried running code-insiders filename
  
  
  • Tried running code-insiders .
  
  
• With no VS Code windows already running
  
  
  
  • Tried running code-insiders from my home directory
  
  
  • Tried running code-insiders filename
  
  
  • Tried running code-insiders .
  
  

None of these scenarios resulted in a duplicate icon showing up in the dock. I suspect that the Mojave update fixed this but since I updated both in the last couple of days, I don't know that for sure.

[bpasero]

@fourcels please try with 10.14.1 and let us know if it still reproduces

[fourcels]

@bpasero I will try when 10.14.1 release

[bpasero]

Thanks

[fourcels]

@bpasero I have tried on 10.14.1, it still reproduces

Below script save as code command, work fine for me

#!/usr/bin/env bash

open -b com.microsoft.VSCode "$@"

[bpasero]

@joaomoreno ⬆️

[joaomoreno]

@fourcels That's good, but you lose most command line powers (--install-extension, for example).

Really no idea why this duplicate icon happens. :thinking:

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[johnnytemp]

According to #62536, a temporary solution is this (for quick reference):

Ah, MacOS Mojave has started adding "Recent Applications" to the dock. Here's an article that shows how you can turn off that

[fgimian]

I'm experiencing the same problem here and can confirm that it only seems to happen with Visual Studio Code on my system (Sublime Text with subl is fine).

Some interesting discoveries:

Just running this command alone reproduces the problem:

ELECTRON_RUN_AS_NODE=1 "/Applications/Visual Studio Code.app/Contents/MacOS/Electron" "/Applications/Visual Studio Code.app/Contents/Resources/app/out/cli.js"

Further to this, the issue ONLY occurs if Visual Studio Code is already running.

[MikeMcQuaid]

Below script save as code command, work fine for me

#!/usr/bin/env bash

open -b com.microsoft.VSCode "$@"

Could the code script that ships with VSCode be updated to do something similar?

[MikeMcQuaid]

(to be explicit: if "yes" I'm happy to open a PR)

[MikeMcQuaid]

Sorry, missed this:

@fourcels That's good, but you lose most command line powers (--install-extension, for example).

@joaomoreno as that doesn't trigger an UI/duplicate for me would/could it be acceptable to use something like that in the script only in the situations in which a UI window would be opened?

[joaomoreno]

I'd be much more interested in finding out why it is that macOS creates separate icons for Code and fix that problem at the root. Have you tried Atom? Does it have the same issue?

[segevfiner]

It seems the trigger is executing the binary from the app bundle directly. Whether that's supposed to happen when you do that or there is some API way to prevent it, I don't know.

I think that is Atom's start script and the commands it uses to launch on macOS: atom.sh116:121 and it's using open to launch when there is no cli output. That was probably so that the shell doesn't block on the atom command when launching the UI.

Maybe Atom has the same issue when running a command with output? But maybe not... Maybe it only happens when you create a "window" even if you don't make it visible (Which VS Code does)... Those are only guesses though, and it remains to be investigated.

[segevfiner]

Note that open might cause issues with env var propagation which currently partially works.

[McTano]

Maybe Atom has the same issue when running a command with output? But maybe not... Maybe it only happens when you create a "window" even if you don't make it visible (Which VS Code does)... Those are only guesses though, and it remains to be investigated.

I found this page because I'm having the same issue with atom on Mojave.
I installed it using Brew, but I've checked the shell script on my system, and those lines are the same as the one you linked.

Whatever's going on in the atom shell script does not solve the issue. It seems like it is a Mojave issue, but maybe we can work around it by adjusting the options passed to open.

[warpdesign]

I can confirm the problem with a fresh install of Mojave 10.14.3. This only happens when starting code from terminal and it's already running, and if that option is activated in the Dock preferences (if it's not, macOS does not add recent apps at the right of the dock so it's not a problem of course):

[mattmc3]

All the information pointing to "Show recent applications in Dock" being the issue seems to be very wrong to me. I do not, and never have, liked having that checked. Even without it, it still dupes up the VSCode icon on my dock when I type code . in the terminal. I have tried using "alt-click, options, Remove from Dock" on the original icon, and then "alt-click, options, Keep in Dock" on the new one. That will fix it for the current terminal session, however, opening a new terminal tab and typing code . gives me a brand new duplicate. I never get more than one extra though. I'm on Mojave 10.14.4.

[mattmc3]

Just as a point of contrast, Atom does not share this problem. When running atom . from a terminal window, this is the script that executes. Atom appears to be doing a lot more than VSCode to set itself up, but I suspect at the end of the day the open command is what makes the difference.

[dt665m]

macos Mojave 10.4.14 still exhibits this behavior.

[whoisnnamdi]

Anyone reach a fix here? Seeing similar issue on one computer, but not the other. Very strange

[PapaCodio]

Just to add to this issue, it also happens when using debugger tools with links to the codebase that open vsCode (such as chrome debugger).

-The unexpected behavior only happens when vsCode is already running.
-When the application is not running and already in the dock vsCode opens as expected.
-When using finder or the dock to open a file and a new window is caused to be opened everything behaves as expected (ie no temporary icon described bellow).

Turning off recent applications does seem to solve multiple copies staying in the dock, however (Mojave 10.14.5 & vsCode 1.36.1) still tries to put a new icon on the end of the dock before the "running app indicator" collapses into the already docked (and running) icon, then the dock removes the "no longer active" icon.

This behavior appears to be the same behavior as when the recent applications in dock option is checked, therefore I'm not sure that it is directly related to the Mojave feature directly as not all ways to open vsCode trigger the behavior and no other apps i personally open from the terminal behave this way.

[dallanlee]

Also seeing this behavior in macOS Catalina (10.15 Beta)

[archmagece]

mac mojava 1.14.5
Same problem here.

[jcafowler]

Has anyone found any updated answers to this problem?

[chrisnorwood]

^^ I've been wondering about this too!

[Gemerz]

+1

[walkersutton]

Same problem on macOS Catalina 10.15

[nsafai]

+1 on macOS Mojave 10.14.6

[lucianoshl]

+1

[pgoodbread]

+1

[DavidGoldman]

This issue appears to happen on macOS whenever multiple instances of an application are spawned via the command line instead of through LaunchServices (e.g. open or NSWorkspace). On macOS, one does not normally spawn applications directly, which is why it's not surprising that only VSCode is running into this issue in practice. For some reason it does not seem to be perfectly reproducible with VSCode, but I'm not sure why.

For instance, with sublime text:

$ "/Applications/Sublime Text.app/Contents/MacOS/Sublime Text"

then in a separate shell:

$ "/Applications/Sublime Text.app/Contents/MacOS/Sublime Text"

will show 2 versions of Sublime Text in the dock.

Interestingly enough Chrome works around this behavior:

$ "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"

then in a separate shell:

$ "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"`
Opening in existing browser session.

Chrome is smart enough to realize that it is already open and reuse existing app. For a split second though, Chrome does appear in the Recent area of the dock but disappears because it closes itself. Does VSCode implement similar behavior? Perhaps sometimes this behavior fails which triggers new instances of the app to run?

The VSCode CLI is quite complicated though, I'm not sure how easy it would be to port it to use the LaunchServices API, NSWorkspace API (which are for some reason deprecated but should still work - it's what open uses under the hood), or even open itself.

FWIW the open command appears to respect env vars:

$ export TEST_ENV="Testing for Visual Studio Code" && open -a /Applications/Visual\ Studio\ Code.app
$ ps aux -E | grep /Applications/Visual\ Studio\ Code.app/Contents/MacOS/Electron

and you'll see TEST_ENV=Testing for Visual Studio Code in the list of environment variables. I'm not sure how well this behaves if an instance of Visual Studio Code is already running though although open does have a -n option to force a new instance to open.

[DavidGoldman]

Also note that if you launch 2 separate sublime text instances via:

$ open -n -a /Applications/Sublime\ Text.app

then Sublime Text will appear twice in the Recents section of the dock. While this may be a bug in macOS, it suggests that when this happens for VSCode there are multiple VSCode processes running. @bpasero thoughts?

[DavidGoldman]

Figured out how to reproduce this: make sure all instances of VSCode are removed from the dock's recent section and then just run code from the command line multiple times. The subsequent code launches will trigger a new VSCode icon in the dock which immediately deactivates (no dot underneath), meaning that the processes ends.

I'm not sure why this sometimes is not an issue though.

[segevfiner]

The question remains. What's macOS logic for associating icons in the recents dock section to the app? It doesn't seem to be documented and it is hard to figure out how to fix it without that.

[bpasero]

I can reproduce (which I expected given reports). Here is what happens on startup of a second instance:

• we do not use the open command (yes this may be the root issue)
• we run Electron with ELECTRON_RUN_AS_NODE to invoke our CLI script
• we eventually start a second instance of VSCode
• we try to connect on a socket to see if another instance is running
• if it does, we immediately hide the dock icon (this does not seem to help for the recent entries):
  https://github.com/microsoft/vscode/blob/bacf3ba1630fab98c8b166dd99dbf629813af479/src/vs/code/electron-main/main.ts#L218
• we terminate after passing over the CLI arguments to the first instance

Now interestingly I cannot reproduce, neither when I run the same code "out of sources" nor when I build VSCode locally (the OSS flavour via gulp vscode-darwin).

I wonder if there is something our build machine does to the application bundle that I am not doing locally that may cause this. Also, we use a Microsoft flavour of Electron build, but not sure if that would make any difference.

[MikeMcQuaid]

@bpasero Thanks for reproducing! It may be useful and worth noting (just in case it's buried from above) that Atom doesn't have the same problem and is also based on Electron (https://github.com/atom/atom/blob/ba3d63bc8546765eeeeb2be7ff93b89e274474e8/atom.sh#L141-L151). I submitted a (hacky) version to demonstrate how this could work with no - arguments specified that was using locally (until the - stuff became too annoying): https://github.com/microsoft/vscode/pull/72056. Happy to help with this any more however I can.

• we do not use the open command (yes this may be the root issue)

TL;DR: yes, I think this is the case as if you use this there's no duplicates.

[bpasero]

Still, I cannot reproduce with our OSS flavour of build where we also do not use open command. So I really want to understand the difference...

[MikeMcQuaid]

Still, I cannot reproduce with our OSS flavour of build where we also do not use open command. So I really want to understand the difference...

@bpasero Is that downloadable from somewhere?

[DavidGoldman]

I can reproduce (which I expected given reports). Here is what happens on startup of a second instance:

• we do not use the open command (yes this may be the root issue)
• we run Electron with ELECTRON_RUN_AS_NODE to invoke our CLI script
• we eventually start a second instance of VSCode
• we try to connect on a socket to see if another instance is running
• if it does, we immediately hide the dock icon (this does not seem to help for the recent entries):
  https://github.com/microsoft/vscode/blob/bacf3ba1630fab98c8b166dd99dbf629813af479/src/vs/code/electron-main/main.ts#L218
• we terminate after passing over the CLI arguments to the first instance

Now interestingly I cannot reproduce, neither when I run the same code "out of sources" nor when I build VSCode locally (the OSS flavour via gulp vscode-darwin).

I wonder if there is something our build machine does to the application bundle that I am not doing locally that may cause this. Also, we use a Microsoft flavour of Electron build, but not sure if that would make any difference.

Can you build your own version of VSCode on your build servers? Maybe try adding logs around the app.dock.hide(); call and potentially call app.dock.isVisible(); although I'm not sure if that will recognize the recents section.

Besides code differences I'm not sure what else could cause this? Minifying? Code signing perhaps?

@bpasero Thanks for reproducing! It may be useful and worth noting (just in case it's buried from above) that Atom doesn't have the same problem and is also based on Electron (https://github.com/atom/atom/blob/ba3d63bc8546765eeeeb2be7ff93b89e274474e8/atom.sh#L141-L151). I submitted a (hacky) version to demonstrate how this could work with no - arguments specified that was using locally (until the - stuff became too annoying): #72056. Happy to help with this any more however I can.

• we do not use the open command (yes this may be the root issue)

TL;DR: yes, I think this is the case as if you use this there's no duplicates.

See my comments above, using open is not required. Using open will work since by default it only launches one process, but from my comments you can launch Chrome manually via the command line and it will close itself to merge with the already running instance just like VSCode is trying to do.

[bpasero]

I have uploaded "Code - OSS.app" to try to reproduce here: https://1drv.ms/u/s!AlosdmnPnzYbolsXqv_cEEjjMrUV?e=Wi1agg

Yes, ideally I want to solve this without having to use the open command. app.dock.hide() does not seem to have any impact on the "Recently opened" list I think.

[bpasero]

This is the visual behaviour when running ./Code - OSS.app/Contents/MacOS/Electron while Code OSS is already running. That is what I would expect, given that we hide the dock.

For code proper (and insiders) I do not even see this icon appearing and disappearing?

[DavidGoldman]

I do sometimes have difficulty reproducing this with Visual Studio Code though - I'm not sure what's breaking. If you're still able to reproduce this, does it still happen after restarting the Dock process?

e.g. killall Dock

It might be best to file a radar/feedback ticket against Apple for this

[bpasero]

@DavidGoldman I can reproduce everytime (I am on macOS 10.14.6). There seems to be a maximum of 3 recent apps allowed, but each time I run code-insidersfrom the command line a new entry shows up for me on the right hand side of the dock after the separator.

[MikeMcQuaid]

I have uploaded "Code - OSS.app" to try to reproduce here: https://1drv.ms/u/s!AlosdmnPnzYbolsXqv_cEEjjMrUV?e=Wi1agg

@bpasero using this build I cannot reproduce this bug. When using ~/Downloads/VSCode-darwin/Code\ -\ OSS.app/Contents/Resources/app/bin/code . to open the current directory in multiple directories I see the icon appear in the "recent apps" section of the dock and then immediately disappear. In comparison, code . appears in recent apps with the dot indicating it's running, the dot disappears and the icon sticks around. If I remove all icons from recent apps I get a new entry added every time I run code ..

Code signing perhaps?

This smells like it could be related.

If you're still able to reproduce this, does it still happen after restarting the Dock process? e.g. killall Dock

@DavidGoldman For completeness: yes, if I do that I see exactly the same behaviour on macOS 10.15.1 Catalina (and previously saw the same on 10.14 Mojave).

It might be best to file a radar/feedback ticket against Apple for this

With my Homebrew maintainer hat on: this is probably not a bad idea but also unlikely to see a timely (or any) resolution from Apple on an issue like this.

[bpasero]

@MikeMcQuaid for me it reproduces with Code (proper) even when I run something like:

/Applications/Visual\ Studio\ Code\ -\ Insiders.app/Contents/MacOS/Electron

I wonder if in that case any signing is respected.

[bpasero]

Something I don't understand, the icon seems different to me for the subsequent entries:

Anyone else seeing that?

[marclundgren]

@bpasero I'm pretty sure that's just an optical illusion. Change your background to a non-gradient and try it again

[TautvydasDerzinskas]

I'm still getting this with Catalina 10.15.2

Am I alone? :)

[vipul-8192]

I am facing the same problem.

Is anybody working on fixing this issue?

On Sun, Dec 15, 2019 at 10:34 PM Tautvydas Derzinskas <
[email protected]> wrote:

I'm still getting this with Catalina 10.15.2

Am I alone? :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/60579?email_source=notifications&email_token=AIGSC5WJP2MUZQF7LMADLRLQYZPRBA5CNFSM4F22TGU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG45OII#issuecomment-565827361,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIGSC5SZW5XFD5NOZHKDPDLQYZPRBANCNFSM4F22TGUQ
.

--
Thanks & Regards

Vipul Aggarwal
[phone]
vipul.[email protected]

[mittalyashu]

Having those multiple VS Code icons showing up in recents is helpful and we can easily switch between different opened workspaces.

It does not show the name of the workspace in the title or the active opened file, that way at-least we can distinguish between different VS Code instances.

[glazey132]

I'm still getting this with Catalina 10.15.2

Am I alone? :)

Nope I'm still seeing this. It looks like we might just have to live with this for the foreseeable future? Has anyone found a work around that doesn't involve setting code as an alias? like @MikeMcQuaid mentioned:

Below script save as code command, work fine for me

#!/usr/bin/env bash

open -b com.microsoft.VSCode "$@"

Could the code script that ships with VSCode be updated to do something similar?

[DavidGoldman]

I do think that the most straightforward solution will be to use open as it's unclear why the Dock is behaving as it is.

One thing that you can try doing is opening Console.app, enabling Info and Debug messages via the Action menu and then filtering for both Visual Studio and Dock and reproducing the issue. In case the logs are private, you can enable private logging.

From my limited testing, it seems when the issue does reproduce, the dock is seeing events in roughly the following order for VSCode, which perhaps it uses? It's unclear if it's unrelated:

• kLSNotifyApplicationCreation
• kLSNotifyApplicationReady
• kLSNotifyApplicationTypeChanged
• kLSNotifyApplicationBecameFrontmost
• kLSNotifyApplicationDeath

But when it doesn't reproduce I see things like:

• kLSNotifyApplicationCreation
• kLSNotifyApplicationReady
• kLSNotifyApplicationDeath

e.g. don't see the TypeChanged or BecameFrontmost, but I'm not sure what triggers them.

EDIT: One other thing to test out, does running code --list-extensions also trigger the issue?

[sjackman]

One other thing to test out, does running code --list-extensions also trigger the issue?

code --list-extensions does not trigger this issue.
open -b com.microsoft.VSCode does not trigger this issue.
/usr/local/bin/code does trigger this issue.

@MikeMcQuaid's workaround works for me:

alias code='open -b com.microsoft.VSCode "$@"'

[DavidGoldman]

One other thing to test out, does running code --list-extensions also trigger the issue?

code --list-extensions does not trigger this issue.
open -b com.microsoft.VSCode does not trigger this issue.
/usr/local/bin/code does trigger this issue.

@MikeMcQuaid's workaround works for me:

alias code='open -b com.microsoft.VSCode "$@"'

Looks like this is reproducible even with /Applications/Visual\ Studio\ Code\ -\ Insiders.app/Contents/MacOS/Electron so I wonder if this actually something with the main entry point of Electron or instead something that VSCode is doing?

[uberbrady]

I did a slightly modified version of this workaround - because it doesn't seem to work if you try to call code on a nonexistent file (in order to create said file and edit it) -

code() {
    if [ ! -e "$@" ]
    then
        touch "$@"
    fi
    open -b com.microsoft.VSCode "$@"
}

[stevenguh]

I have another workaround that would allow you to pipe content to code. Note that this would not able open a nonexistent file.

code() { 
    if [ -t 1 ] && [ -t 0 ]; then 
        open -a Visual\ Studio\ Code.app "$@"
    else 
        open -a Visual\ Studio\ Code.app -f
    fi
}

[weinand]

I can no longer reproduce this issue with VS Code 1.50 or 1.51 (Insiders) on macOS Catalina 10.15.7.

When starting VS Code from the command line, another icon appears in the Dock for 0.3 seconds and then disappears.

Are others seeing different behavior?

[bpasero]

This issue is about seeing multiple Code icons in the recent portion of the dock:

Only reproduces when you enable this setting:

[weinand]

Oh, I see. Yes, that issue still exists.

[afumagalli]

This issue appears to be fixed in Big Sur

[weinand]

Yes, I can confirm that this is fixed in macOS Big Sur.