Change:
opens in a window instead of running in background. I have seen , which introduced this behavior. For me, means . Console window breaks it completely. If the window is closed - service is gone, what shouldn't happen. I understand that there were reasons about changing service behavior to ordinary application. However, I would really like service-like functionality back for my remote development. It's perfectly fine if this would be an additional installation flag. That would keep current easy behavior and allow for unattended installs. <!-- 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 (System) OS Version: Windows 11 22H2 Steps to Reproduce:
Sorry, misread. Will look at that
I believe this issue is only partially fixed, even in . The window does not appear when only or (the cli) is running, however, as soon as a tunnel is connected to, a window appears (as code- is run). If the user closes the window, the tunnel connection is dropped. I believe the fix is to pass to creationflags in as seen here: However, without the proprietary "mixin" , it seems my builds of code cli are not able to properly run code-server, failing with To reproduce the issue, on a windows machine: an arbitrary tunnel to authorize the machine: the tunnel with the code at the tunnel service with connect to the tunnel again a on the desktop, close it and observe the tunnel disconnect on

Discussion:
let tracer = SdkTracerProvider::builder().build().tracer("codecli"); let mut log = log::Logger::new(tracer, log_level); if let Some(f) = &core.global_options.log_to_file { <del> log = log.tee(log::FileLogSink::new(log_level, f).expect("expected to make file logger")) </del> <ins> log = log .with_sink(log::FileLogSink::new(log_level, f).expect("expected to make file logger")) </ins> } log

use async_trait::async_trait; use shell_escape::windows::escape as shell_escape; <ins> use std::os::windows::process::CommandExt; </ins> use std::{ path::PathBuf, process::{Command, Stdio}, }; <ins> use winapi::um::winbase::{CREATE_NEW_PROCESS_GROUP, DETACHED_PROCESS}; </ins> use winreg::{enums::HKEY_CURRENT_USER, RegKey}; use crate::{

use super::service::{tail_log_file, ServiceContainer, ServiceManager as CliServiceManager}; <ins> const DID_LAUNCH_AS_HIDDEN_PROCESS: &str = "VSCODE_CLI_DID_LAUNCH_AS_HIDDEN_PROCESS"; </ins> pub struct WindowsService { log: log::Logger, tunnel_lock: PathBuf,

launcher_paths: LauncherPaths, mut handle: impl 'static + ServiceContainer, ) -> Result<(), AnyError> { <del> handle.run_service(self.log, launcher_paths).await </del> <ins> if std::env::var(DID_LAUNCH_AS_HIDDEN_PROCESS).is_ok() { return handle.run_service(self.log, launcher_paths).await; } // Start as a hidden subprocess to avoid showing cmd.exe on startup. // Fixes https://github.com/microsoft/vscode/issues/184058 // I also tried the winapi ShowWindow, but that didn't yield fruit. Command::new(std::env::current_exe().unwrap()) .args(std::env::args().skip(1)) .env(DID_LAUNCH_AS_HIDDEN_PROCESS, "1") .stderr(Stdio::null()) .stdout(Stdio::null()) .stdin(Stdio::null()) .creation_flags(CREATE_NEW_PROCESS_GROUP | DETACHED_PROCESS) .spawn() .map_err(|e| wrap(e, "error starting nested process"))?; Ok(()) </ins> } async fn unregister(&self) -> Result<(), AnyError> {