Change:
if (this._ptyProcess) { await this._throttleKillSpawn(); this._logService.trace('IPty#kill'); <del> this._ptyProcess.kill(); </del> <ins> this._ptyProcess.kill(!isWindows ? 'SIGKILL' : undefined); </ins> } } catch (ex) { // Swallow, the pty has already been killed

Discussion:
Testing Regardless of , for every terminals in a window, and restarts, there are processes shown in the activity monitor. https://user-
quit and reopened again and now there are 6 <img width="1729" alt="Screenshot 2023-02-21 at 11 24 51 AM" src="https://user-"
other info: <img width="476" alt="Screenshot 2023-02-21 at 11 29 41 AM" src="https://user-"
I don't have to even type in/ interact with the terminal for this to happen
Are the processes really still running or some zombie processes simply not cleaned up? I remember having seen that on Linux from time to time, but not on macOS. Also, does this reproduce when you reload the window instead of restart?
They're not listed as zombie processes, so I believe they're still running. Reloading neither creates nor destroys processes !
I have to select to kill them
Similar issue on Linux. On Ubuntu 22.04 on macOS Parallels, the shell integration scripts remain after closing code-insiders: . Using , the status of those processes is (waiting for an event to complete, and is a "session leader in the foreground process group"). I'm wondering whether something might be causing the shell integration scripts to fail to complete?
interesting finding . just confirmed this doesn't reproduce when I disable shell integration
not seeing this with bash anymore - only zsh
also not reproducing with zsh anymore, though I'm sure it's still an issue because when I initially opened activity monitor (with zero terminals), I had 50+ zsh processes reported
I can easily reproduce this in a vanilla Ubuntu using bash. The problem is the shell integration shell traps signals and ignores SIGTERM. The SIGKILL signal works just fine.
Repro out of sources on mac: shell integration a terminal , count procs +c (doesn't repro on cmd+q) , :bug: count is the same
Can repro using this profile in 1.76.2: Could this be related to the posix spawn change in node-pty?

The posix spawn change and other node-pty changes came in on Jan 19:
Yes, there's this too
Better repro for OSS:
This can be reproduced in OSS with: ./scripts/code- shell integration a terminal | grep bash, count procs VS Code process explorer, get main process PID -s SIGKILL <main process PID| grep bash, count is the same After downgrading node-pty, it does not reproduce: I'm going to need some help on this one, something between node-pty and node-pty caused this problem. Unfortunately it's not really possible to tell the exact commits that each beta build points at, the bundles are fairly small though. My guess is it's because of since that blocked me from upgrading for over a year.
I can investigate this today.
Minimal test case to repro the leak.
The issue doesn't seem to be resolved in version 1.77, as stated in
The fix has not been merged into , it is available in and will be available in
On Gnome, this also causes a massive lag during the shutdown. Stale , also ignores SIGTERM sent during the shutdown, which waits for two minutes and finally sends SIGKILL. Hopefully, 1.78 will fix this as well.
Per : On MacOS the processes are properly killed when explicitly closing the workspace window, but remain running if you simply quit VSCode without closing the window. This behavior is the same even with set to false. It is the same in all three modes of .
thanks for that info. by "quit VS code" I assume you mean via the mac dock? !
Quitting via Cmd-Q. But the same happens when quitting via the dock. Cmd-Shift-W to close the window terminates all running shells.
does the issue repro on insiders as well ?
Issue does not repro on insiders. Insiders version fixes the issue, all terminals / processes correctly exit upon Cmd-Q quit.
Thanks for confirming, the fix will be available with next week.