I’m using 2 instances scenario. And I faced with even if I run 1st instance with “syncthing --no-browser --no-console” and it usually closes the window (even I saw it may not close sometimes), second instance command “syncthing --no-browser --no-console --home=%LOCALAPPDATA%\” does not close the console window
The problem is that most users probably don’t want to disable Windows Terminal and go back to the old console as their default shell. I think we should probably recommend the Task Scheduler way as the main method to run Syncthing hidden, because that one can always hide the console window even without using --no-console with Syncthing.
In other words, the Startup folder solution isn’t really viable anymore, at least not as a general recommendation.
For me run: minimized had (still has, as long as I’m not a usual Windows user) the merit of completely hiding the console. --no-console does its own job OK (--no-console all alone, the console won’t even show as a stable terminal application button in the task bar) and run: minimized just prevents the stealth window/button on startup… all fine… for me with single instance… in friends computers.
Windows Terminal does not completely replace the default PowerShell (even within Windows Terminal, Start-Process may invoke the legacy PowerShell). Using Start-Process in PowerShell correctly hides the command line window. Therefore, when creating a shortcut, you can first call PowerShell and then use PowerShell to create the Syncthing process.
The shortcut should point to:
(Replace C:\Program Files\Syncthing\syncthing.exe with the actual path to your Syncthing executable. )
This approach ensures no window appears when starting the shortcut, whether manually or via the startup folder.
Be aware that the field is capped at 260 characters. This may be not enough is you use additional options like --log-level= and --home= whose powershell syntax hogs ~66 for itself (omitting .exe).
Worse, Windows replaces first powershell.exe with its full path c:\Win…system32.…\v1.0
You will also have to customise the shortcut icon.
You can spare --no-browser characters by setting the option into the GUI (Action/Settings/GUI uncheck Start browser).
You may also spare some characters using --home=%LOCALAPPDATA%\Syncthing and if you have syncthing.exe out of the %PATH% like I do, you can use %HOMEPATH%\Sync\syncthing[.exe] or %USERPROFILE%\Sync\syncthing[.exe] --no-console --log-level=WARN --home=%LOCALAPPDATA%\Syncthing
Hi Lionheart
Welcome here. I gave a try with your way. Unfortunately, even when the shortcut is instructed to run in minimized window powershell spits at least one stealth window (2 if we don’t use minimized)
PowerShell natively supports hiding windows. By adding a few parameters, you can prevent the second window from appearing (the first window will still appear, but as you mentioned, properly configuring the shortcut can avoid the window briefly stealing focus, though it will still flash momentarily in the taskbar). Like this:
$PSScriptRoot indicates the relative location of the executable file to the script file, and $env:LOCALAPPDATA is how %LOCALAPPDATA% is represented in PowerShell. If you need to prevent a fleeting window from stealing focus, you still need to set the shortcut to run minimized, but at least the issue of a persistent window appearing is resolved. Perhaps due to different versions of Windows Terminal, simply adding --no-console to the shortcut doesn’t work on my computer somehow.
I know that writing a VBS script can completely hide the window, and not even a fleeting icon will appear in the taskbar. However, I don’t know how to write a VBS script.
Indeed, I had noticed the information earlier. When looking up information about hiding the console, VBS was mentioned, so I mentioned it in passing. I’ve even tried using sc create to register Syncthing directly as a service, but running these programs under the System account makes me somewhat concerned about security. Moreover, because Syncthing isn’t designed to be a Windows service, Windows cannot correctly identify the service’s running status (the program can actually run normally, but it’s displayed as not started).
–no-console is not --no-browser. Are we talking about the same thing ? In old Windows I had to write shortcut target this way "c:\users\me\Sync\syncthing.exe" --no-console. --home should be in the end, maybe because parsing issue I don’t understand (maybe space in argument or accepted for some parameter): "c:\users\me\Sync\syncthing.exe" --no-console --log-level=WARN --home=path
double dash syntax is no relevant as it is the new mandatory syntax.
--no-console parameter does not take effect on computers with Windows Terminal installed, resulting in persistently lingering windows. The --no-browser parameter has always worked as expected. There is no order dependency among the launch parameters passed to the application. By convention, if there are spaces within a parameter, quotation marks must be used to specify the start and end positions of the parameter. This is why the file path in shortcuts is enclosed in double quotes by default—because Windows allows spaces in directory names. If there are no spaces, the presence or absence of quotes does not affect the execution. Moreover, if the parameter itself contains quotes, I used single quotes and backticks to escape the quotes to avoid ambiguity and prevent incorrect parameter termination. This code has been repeatedly tested on my computer at the very least.
If you’re not clear about how the --no-console parameter behaves on my computer, I can attach a screenshot to help clarify.
Windows Terminal has taken over and replaced the default Windows CMD.exe, altering the expected behavior of cmd.exe. If you simply set the shortcut to minimize, a Windows Terminal window will always remain on the taskbar. Once you close the window or the Syncthing tab, Syncthing itself will also shutdown, resulting in the --no-console parameter having no effect at all (as discussed in the GitHub link at the top of the post). If you revert CMD to its default settings within Windows Terminal, you lose the convenience of using Windows Terminal to aggregate CMD and PowerShell windows. In other words, as tomasz86 mentioned, I don’t want to switch back to the old-fashioned CMD shell just because the Syncthing window can’t be closed. Managing Syncthing through the Task Scheduler every time is too cumbersome. What I want to achieve is a solution that allows me to “place a shortcut on the desktop for easy access, put it in the Startup folder for automatic launch, avoid modifying Windows Terminal’s window settings, and not worry about the security risks associated with excessive System user permissions”.
That’s super odd to me — I have two Win11 Devices, both with Windows Terminal, and neither exhibits this issue.
Both of them are configured with Task Scheduler to run at startup. The action taken is to execute the Syncthing binary with --no console --no-browser in the arguments field. And it works the way I want it to.
Sorry I didn’t understood Windows Terminal is yet-another-new-Windows-thing-which-breaks-things-as-always. I though you were talking about cmd windows. Maybe WT has it’s own settings that can be customized depending on the invocation name. I remember cmd had this, e.g. font color could be set different and stored for later use depending we ran Win+R cmd enter or clicking a shortcut with different name (alias) in menu (e.g Command prompt) or elsewhere. Maybe also you could fill a bug in github. Task scheduler is a good for set it and forget it as an alternative for running ST as non-system account on boot (kind of user service), but I must admit it is far too heavy when you need to fully stop ST (I don’t say restart with the GUI) then start it again several times in a short while (tests purposes or so).
.
You will also have to customise the shortcut icon.
(see 
Indeed, I had noticed the information earlier. When looking up information about hiding the console, VBS was mentioned, so I mentioned it in passing. I’ve even tried using 