Change:
// Setup the CLI server to support forwarding commands run from the CLI const ipcHandlePath = createRandomIPCHandle(); env.VSCODE_IPC_HOOK_CLI = ipcHandlePath; <ins> const persistentProcessId = await this._ptyService.createProcess(shellLaunchConfig, initialCwd, args.cols, args.rows, args.unicodeVersion, env, baseEnv, args.options, args.shouldPersistTerminal, args.workspaceId, args.workspaceName); </ins> const commandsExecuter: ICommandsExecuter = { <del> executeCommand: <T>(id: string, ...args: any[]): Promise<T> => this._executeCommand(id, args, uriTransformer) </del> <ins> executeCommand: <T>(id: string, ...args: any[]): Promise<T> => this._executeCommand(persistentProcessId, id, args, uriTransformer) </ins> }; const cliServer = new CLIServerBase(commandsExecuter, this._logService, ipcHandlePath); <del> const id = await this._ptyService.createProcess(shellLaunchConfig, initialCwd, args.cols, args.rows, args.unicodeVersion, env, baseEnv, args.options, args.shouldPersistTerminal, args.workspaceId, args.workspaceName); this._ptyService.onProcessExit(e => e.id === id && cliServer.dispose()); </del> <ins> this._ptyService.onProcessExit(e => e.id === persistentProcessId && cliServer.dispose()); </ins> return { <del> persistentTerminalId: id, </del> <ins> persistentTerminalId: persistentProcessId, </ins> resolvedShellLaunchConfig: shellLaunchConfig }; } <del> private _executeCommand<T>(commandId: string, commandArgs: any[], uriTransformer: IURITransformer): Promise<T> { </del> <ins> private _executeCommand<T>(persistentProcessId: number, commandId: string, commandArgs: any[], uriTransformer: IURITransformer): Promise<T> { </ins> let resolve!: (data: any) => void; let reject!: (err: any) => void; const result = new Promise<T>((_resolve, _reject) => {

Discussion:
Issue Type: <bBug</b- Open in vscode Open in vscode In the integrated terminal of vscode project2 run command Expected behaviour: Window that was should now have open. Actual Result: All vscode windows change to have open. Possibly related to VS Code version: Code 1.55.2 (, 2021-04-13T09:35:57.887Z) OS version: WindowsNT x64 10.0. Remote OS version: Linux x64 5.4.0-48-generic Remote OS version: Linux x64 5.4.0-48-generic <details<summarySystem Info</summary </details<details<summaryExtensions (28)</summaryExtensionVersion ------ vsc-material-theme33.1.2 vsc-material-theme-icons1.2.2 remote-ssh0.65.4 remote-ssh-edit0.65.4 env-cmd-file-syntax0.2.2 swagger-viewer3.0.1 atlascode2.8.6 gitignore0.6.0 vscode-markdownlint0.40.3 gitlens11.4.1 pipenv-scripts1.0.3 rest-client0.24.5 git-graph1.30.0 python2021.4. jupyter2021.5. vsliveshare1.0.4131 vsliveshare-audio0.1.91 vsliveshare-pack0.4.0 autodocstring0.5.4 open-in-new-window1.0.0 vscode-yaml0.18.0 rust0.7.8 vscode-coverage-gutters2.7.2 file-tree-generator1.1.1 markdowntable0.5.1 serverless-ide-vscode0.5.31 shellcheck0.14.1 markdown-all-in-one3.4.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This seems specific to remote when I see the details in the issue.
When asking a co-worker to try reproduce they didn't see the issue, they were not using remote. So yes this might be an issue when using remote.
I can reproduce.

open 2 WSL window in the dev tools of both windows set breakpoints in where _remoteCLI.windowOpen is handled in one of the terminals run (resp or ) both breakpoints are hit Looks like a regression introduced by the refactoring to make the terminal process a child of server process. Each terminal process runs a CLI server that is used by the command. That server talks to a renderer window, which should be the window in which the terminal is used. That window then talks to main with the reload.
I cannot reproduce in 1.53.2 I cannot reproduce in 1.54.3 I can reproduce in 1.55.2 I think this was working correctly in the past with the server spawned terminals, but it was introduced by a more recent refactoring
Yes, this is recent issue, as my usual workflow has been to move to the project in the integrated terminal and use to open the project, and I try to stay up to date with VSCode versions.
It's a bug. has be broken a long time
Still not fixed. I found it have been moved to Backlog, It's a bug which broken -r option, When it will be fixed?
I'm having a similar issue with my git config editor (). It used to open the commit message in the existing window and now it opens a new one. I also suspect is related since it looks you're assigned to both this and that issue
yup, same here, I'm still using the old version 1.56.2 due to this issue
I have been able to temporarily fix this issue by starting up VSCode with extensions disabled. It works when disabled, it works immediately after enabling them again, and works for a days after still. Then randomly stops. Not had enough experiences with the "workaround" to detect a pattern yet. Happy to help isolate this issue if someone wants to reach out to me
Came here from issue . Since that issue is closed and it seems related, I figured I'd update here: in the hopes that this helps narrow it down a little. Breakdown: This happens on version 1.65.1. (Local is Windows 10, remote is Linux/Ubuntu over Windows SSH. No ControlMaster.) This happens both on windows opened from within an existing remote session (remote -terminal -cd <other project directory-code .)

as for new remote sessions (new window -connect current window to host -select host -open folder) While starting the scripts via , it adds the automatically created port forward to all open windows and then opens a tab for every remote in the local environment. I've set up a repository with a test case: And even more peculiar, this triggers existing port forwards to open as tabs (9 in total - 6 from my main project and 3 from the above test). ! Version: Let me know if you need me to create a separate issue.
the result is N windows on the same workspace identifier, which is something that could result in all sorts of issues and is generally unsupported in VSCode. Marking this important for the current milestone. !
I believe this started happening when we introduced the pty host as the message gets broadcast to all windows: But we don't check the pty exists unlike other calls like this: It does not repro in the test resolver because each window gets its own server and pty host. Debt item here would fix this:
Created a PR for this , couldn't test it in Code - OSS though so we'll need to verify when it gets released.
Thanks!!