My suspect is https://github.com/Microsoft/vscode/blob/master/src/vs/platform/environment/node/argv.ts#L87

/cc @joaomoreno

I commented out that code and it still reproduces so it must be something else...

@joaomoreno this might be a regression from using the shared IEnvironmentService also for the main process. A much easier repro is this:

• go into the folder of the Electron executable
• run ./Electron --nolazy someFolder
• notice that Code refuses to open that folder

Debug adds --nolazy to our startup and somehow as soon as you pass an argument to an app that uses minimist for parsing that is not registered as known argument, things go wrong.

If I add nolazy to our list in https://github.com/Microsoft/vscode/blob/master/src/vs/platform/environment/node/argv.ts#L38 this issue is gone.

Any clue?

as soon as you pass an argument to an app that uses minimist for parsing that is not registered as known argument

Probably minimist is parsing --nolazy as an option that takes a string instead of as a boolean flag. So, try adding nolazy as a boolean option in here.

Awesome. Good catch.

@joaomoreno yup, added it. Just sucks that we need to be aware of this in the future. I think it would be better if debug adds their arguments maybe as last thing to the list and not first.

nolazy is a node flag, not a debug flag.

On second thought, the real fix here is to not let Node and Electron arguments reach our system at all. But this is a good quick fix.

I've introduced this issue through this fix #13434
It does not make sense to pass the --nolazy flag here because VS Code controls how the extension host is launched.
@bpasero should I revert this?

I'm no longer adding the --nolazy flag for EH debugging.