Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Opening a file via CLI is causing a duplicate VSCode icons to appear in my Mac's dock. Sometimes it sits there bouncing for a couple minutes as if its trying to open an app that's not responding. Other times they go away after a couple seconds. If I open several files, the icons build up in the dock. Happens with both new and existing files. I believe this behavior first appeared around May. ! Yes. I did the mentioned command to launch without extensions and it still occurred. Even zapped my VSCode install and tried it fresh and still occurred. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.73.1 OS Version: MacOS 12.6.1 VSCode normally so it appears in the dock a terminal program a new or existing file via CLI like behavior
Possible related to
can you share a video demonstrating the issue, please close/force quit all running instances of VSCode and start with in the demo. Thanks!
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Wow, the bot is quite aggressive, it's only been a week. I can try to do this next week, I have been on medical leave from work where I use my Mac. When I follow up, will the issue be able to be reopened?
No worries, I can reopen it now.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
I'm seeing the exact same behavior that is seeing on macOS 13.1, and I would also date the first occurrence to May or June 2022, when the first beta of macOS 13 came out. At first, I thought that one of my extensions was causing the problem, but I can recreate the behavior without a single extension installed. (VSCode 1.74.2, macOS 13.1) Update: I have a video showing the behavior. https://user-
can you provide the output of after the second instance opens.
Sure.
Interesting, the status shows only a single instance is running. Can you also provide the output of when multiple active icons are shown. Additionally to clarify, in the recording you are first launching from the dock and then quit it before launching another instance from the terminal ? Or did you launch the second instance without quitting the first instance ?
I have only minimized the window. The first instance was still running at this point.
Both instances seem to use the same user data dir, can you check if there is a file under after opening first instance and also after opening second instance.
The file is there after starting the first instance and it contains the process id of the electron process. After starting the second instance the file is also there and it contains the process id of the second electron process.
Just saw that I have updated the software. I'm now running VSCode 1.74.3 on macOS 13.2.
Seems like an issue with our singleton instance server, lets confirm that. Can try the following, Close all running instances of VSCode Open the first instance and copy the PID from Get the output of Open the second instance and copy the new PID from Get the output of Paste both the outputs in this issue.
Ah that makes the problem clear, looks like you have configured in your terminal session which causes the second instance launched from the terminal to create singleton server socket at a different location than the first instance when launched from the dock/finder as you can see /cc this is a return of for the singleton instance scenario, since we seem to leading to above incorrect path when launching from dock/finder interface.
To confirm: If I delete the variable from my profile, vscode runs as expected as a single instance
We can obviously not prolong the startup for until the shell environment is resolved because that can take more than 10 seconds. I would argue this scenario is unsupported. Maybe though we should not be supporting any environment variables at all when figuring out the path for the main process IPC handle.
I wonder if we should just warn in the terminal whenever XDGRUNTIMEDIR is set? I also wonder if respecting XDGRUNTIMEDIR should only work on Linux? Thoughts ?
Yes that should be the way to go, the variable only makes sense on Linux since it will be defined by the OS and will be available irrespective of being launched from the terminal or GUI.

Discussion:
return `.pipevscode-git-${id}-sock`; } <del> if (process.env['XDG_RUNTIME_DIR']) { </del> <ins> if (process.platform !== 'darwin' && process.env['XDG_RUNTIME_DIR']) { </ins> return path.join(process.env['XDG_RUNTIME_DIR'] as string, `vscode-git-${id}.sock`); }

return `.pipevscode-ipc-${randomSuffix}-sock`; } <del> // Mac/Unix: use socket file and prefer // XDG_RUNTIME_DIR over tmpDir let result: string; if (XDG_RUNTIME_DIR) { result = join(XDG_RUNTIME_DIR, `vscode-ipc-${randomSuffix}.sock`); } else { result = join(getNodeDependencies().os.tmpdir(), `vscode-ipc-${randomSuffix}.sock`); } </del> <ins> // Mac & Unix: Use socket file // Unix: Prefer XDG_RUNTIME_DIR over user data path const basePath = process.platform !== 'darwin' && XDG_RUNTIME_DIR ? XDG_RUNTIME_DIR : getNodeDependencies().os.tmpdir(); const result = join(basePath, `vscode-ipc-${randomSuffix}.sock`); </ins> // Validate length validateIPCHandleLength(result);

return `.pipe${scope}-${version}-${type}-sock`; } <del> // Mac/Unix: use socket file and prefer // XDG_RUNTIME_DIR over user data path // unless portable // Trim the version and type values for // the socket to prevent too large // file names causing issues: // https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars </del> <ins> // Mac & Unix: Use socket file // Unix: Prefer XDG_RUNTIME_DIR over user data path, unless portable // Trim the version and type values for the socket to prevent too large // file names causing issues: https://unix.stackexchange.com/q/367008 </ins> const versionForSocket = version.substr(0, 4); const typeForSocket = type.substr(0, 6); const scopeForSocket = scope.substr(0, 8); let result: string; <del> if (XDG_RUNTIME_DIR && !process.env['VSCODE_PORTABLE']) { </del> <ins> if (process.platform !== 'darwin' && XDG_RUNTIME_DIR && !process.env['VSCODE_PORTABLE']) { </ins> result = join(XDG_RUNTIME_DIR, `vscode-${scopeForSocket}-${versionForSocket}-${typeForSocket}.sock`); } else { result = join(directoryPath, `${versionForSocket}-${typeForSocket}.sock`);