Change:
Testing <img width="348" alt="image" src="https://user-"
Extension fails to launch child_process during initialization Will check if the issue is isolated to this extension with a minimal example using module
Was able to isolate the issue, firstly as pointed above the extension makes an attempt to launch a child process via the helper which basically emulates options and passes them eventually into Since variant relies on when node executable path is not provided, this will default to use the Electron executable that is used to create the extension host. Now there are two problems with this usage, (i) execa module will not add the env variable, so the exectuable cannot be launched as intended. (ii) We also disable calling Electron executable as unless flag is provided in the call site. For the (ii) we automatically add the flag at both and callsites internally in the runtime, so this should not be a concern for the extension authors. As for (i), if the extension author used the vanilla then the env variable would be set internally by the runtime. But since the call is done via a 3rd party module, I think it is upto the extension authors to ensure the env variable is provided if they rely on the Electron executable. I feel like there is no action required from runtime/VSCode core for this issue, but we should loop in the extension author to fix this on their end. Thoughts ?
So what exactly is different in the utility process vs. child process today? I did not fully understand.
When extension host is created via , internally the runtime would launch the process with env variable set and we never remove this variable explicitly in the extension host after launch (i-e) , this would indirectly help above scenarios since the env gets inherited by extensions. This is not the case with utility process since there is no runtime induced env variable, the extensions have to explicitly add them if they rely on the electron executable. I would say the previous behavior was a hidden bug and is visible now with the utility process api.
Oh yeah understood! I think I somewhat agree that we need to just document this to extension authors.
btw, since this is a public issue, I've shared it with the dendron extension author directly to track
hey, dendron author here. thanks for looping us in on this. so as I understand, we have two options: either use vanilla or set when using the module. is this an accurate understanding?
yup that is correct. To clarify, only when ends up using on the desktop extension host.
Got it. What's the timeline for us patching this? Is this already live in insider?
The change is not default in insiders yet, it is currently behind an environment variable , can give more context on the timeline.
after discussing with the team, we have decided to push a workaround in core to avoid breaking the extension community with the new process type for extension host. You don't need to make the adjustments outlined in

Discussion:
const err = new Error('An extension called process.crash() and this was prevented.'); console.warn(err.stack); }; <ins> // Set ELECTRON_RUN_AS_NODE environment variable for extensions that use // child_process.spawn with process.execPath and expect to run as node process // on the desktop. // Refs https://github.com/microsoft/vscode/issues/151012#issuecomment-1156593228 process.env['ELECTRON_RUN_AS_NODE'] = '1'; </ins> } interface IRendererConnection {