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. --Does this issue occur when all extensions are disabled?: Yes <!-- 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.78.2 (installed via snap) OS Version: Ubuntu 23.04 Steps to Reproduce: Just the status is displayed Lots of errors are displayed before the actual status output
will enable verbose logs from the runtime as well . do you know why runtime logs are enabled in this mode ?
do not fully recall why, but the original feature came in via I think we need to receive the output from the application here: Because we actually write back to the console from the app. We can probably change this to a different argument than if that is the only intent.
I think the real issue here is enabling the electron verbose logging, which is not good I think. Will see if I can fix it.
This is fixed for the most part, but certain logs may still appear: <img width="574" alt="Screenshot 2023-05-31 at 2 52 18 pm" src=""
Hm, could you try your steps again using VS Code insiders: what would cause these low level messages to appear in the output, do you know?
Chromium will always log to stderr for messages that are of severity level or higher ;l=613-630 when no explicit logging destination is provided. If we want to hide these messages, then a better way would be to separate the runtime logs to a separate file destination using and ignore them for mode.
could we pass in unless is used? I am not convinced these messages are helpful, unless maybe we explicitly ask for it.
ignores stderr unless is used.
Can be verified with the build tomorrow (Friday) with the additional changes.
Now when I run I get no output at all. I get some output with . Is that the expected behavior?
you should either a message saying you need to open a window to use this command, or something like this: <img width="887" alt="Screenshot 2023-06-01 at 2 17 52 pm" src=""
I'm on Windows and I do not see this message if the app was launched from the taskbar, but I do see this message after launching with the CLI
Reopening this as it is not merged into release branch yet.
Verification This needs verification on macOS, Windows and Linux have one code insiders window opened from the command line run verify you see status related output verify you do not see Electron/Chrome related output such as
verified on windows
verified on linux
Uh, I see this error on mac. Then it leaves a new insiders app icon open
Verification This needs verification on macOS have one code insiders window opened from the command line run verify you see status related output verify you do not see Electron/Chrome related output such as
when I run that, I see as the output
the next insiders should include the required changes for

Discussion:
const processCallbacks: ((child: ChildProcess) => Promise<void>)[] = []; <del> const verbose = args.verbose; if (verbose) { </del> <ins> if (args.verbose) { </ins> env['ELECTRON_ENABLE_LOGGING'] = '1'; <ins> } if (args.verbose || args.status) { </ins> processCallbacks.push(async child => { child.stdout!.on('data', (data: Buffer) => console.log(data.toString('utf8').trim())); <del> child.stderr!.on('data', (data: Buffer) => console.log(data.toString('utf8').trim())); </del> <ins> child.stderr?.on('data', (data: Buffer) => console.log(data.toString('utf8').trim())); </ins> await Event.toPromise(Event.fromNodeEventEmitter(child, 'exit')); });

// returns a file path where stdin input is written into (write in progress). try { <del> await readFromStdin(stdinFilePath, !!verbose); // throws error if file can not be written </del> <ins> await readFromStdin(stdinFilePath, !!args.verbose); // throws error if file can not be written </ins> // Make sure to open tmp file addArg(argv, stdinFilePath);

// is closed and then exit the waiting process. let waitMarkerFilePath: string | undefined; if (args.wait) { <del> waitMarkerFilePath = createWaitMarkerFileSync(verbose); </del> <ins> waitMarkerFilePath = createWaitMarkerFileSync(args.verbose); </ins> if (waitMarkerFilePath) { addArg(argv, '--waitMarkerFilePath', waitMarkerFilePath); }

env }; <del> if (!verbose) { </del> <ins> if (!args.verbose) { </ins> options['stdio'] = 'ignore'; } let child: ChildProcess; if (!isMacOSBigSurOrNewer) { <del> if (!verbose && args.status) { </del> <ins> if (!args.verbose && args.status) { </ins> options['stdio'] = ['ignore', 'pipe', 'ignore']; // restore ability to see output when --status is used }

// -a opens the given application. spawnArgs.push('-a', process.execPath); // -a: opens a specific application <del> if (verbose || args.status) { </del> <ins> if (args.verbose || args.status) { </ins> spawnArgs.push('--wait-apps'); // `open --wait-apps`: blocks until the launched app is closed (even if they were already running) // The open command only allows for redirecting stderr and stdout to files, // so we make it redirect those to temp files, and then use a logger to // redirect the file output to the console <del> for (const outputType of verbose ? ['stdout', 'stderr'] : ['stdout']) { </del> <ins> for (const outputType of args.verbose ? ['stdout', 'stderr'] : ['stdout']) { </ins> // Tmp file to target output to const tmpName = randomPath(tmpdir(), `code-${outputType}`);