Command-Line Flags¶
The launcher accepts several flags that change its behavior. Flags are passed through the shortcut's Target field; see Adding Flags to a Shortcut for how to set them up.
Flag syntax
All three styles work and are equivalent: /clean, -clean, --clean.
Flags are case-insensitive. Order doesn't matter. Multiple flags can be
combined.
Quick reference¶
| Flag | Purpose |
|---|---|
/clean |
Wipe the local install and re-sync from scratch (with confirmation) |
/yes |
Skip confirmation prompts (use with /clean for unattended runs) |
/verify |
SHA1 hash verification on every copied file (slower, more thorough) |
/skiplaunch |
Run sync but don't launch the application |
/showlog |
Open the log file in Notepad after the launcher exits |
/clean¶
Wipe the local install before sync.
This deletes everything in the local folder (with a few exceptions, listed below) and forces a fresh re-sync from the server. It's the recovery option when something is wrong with the local install.
Exemptions (never deleted by /clean)¶
The launcher preserves these even when /clean is used:
- The
Settings\subfolder and everything in it - The
Pulse Logs\subfolder (where the log lives) ServerPath.txt(the saved server location)- The launcher executable itself, if it happens to be running from inside the client folder
Confirmation¶
By default, /clean shows a confirmation dialog before wiping anything:
The /clean flag was specified.
This will delete all files in: C:\Users...\Pulse Dashboard 5\
The Settings folder will be preserved. After cleaning, the application will be re-synced from the server.
Continue?
Add /yes to skip this prompt — useful in scripted scenarios.
Failure handling¶
If some files can't be deleted (typically because the application is already running), you'll get a "Clean Incomplete" dialog with Retry and Cancel options. Clicking Cancel aborts the launch entirely — the launcher will not proceed to sync or run the application over a partial wipe.
When to use it¶
- A user reports that the application is behaving strangely after an update.
- Files have gone missing or been manually altered locally.
- An IT support call where you want a known-clean baseline.
Example¶
/yes¶
Skip confirmation prompts.
Currently this only affects the /clean confirmation dialog. Without /yes,
the user has to click "Continue?" before /clean proceeds. With /yes, the
clean happens immediately.
/y is accepted as a short alias.
When to use it¶
- Scripted/automated invocations where no human is present to click "Yes".
- Recovery shortcuts placed on a user's desktop where you've decided you don't need them to confirm.
Example¶
/verify¶
Use SHA1 hash verification for every copied file.
By default, the launcher verifies copies by comparing file lengths after the
copy completes. With /verify, it additionally computes SHA1 hashes of source
and destination and compares them. A hash mismatch is treated as a failed copy
and triggers the retry/error flow.
What it catches¶
- Silent byte corruption during copy (rare, but happens with bad RAM, bad disks, or buggy AV software).
- Files that "appear identical" by length and timestamp but actually differ in content.
Cost¶
Strict-mode verification reads every copied file twice (once on the server, once locally). The cost scales with how much actually changed, not total file count — files that are skipped because they already match aren't read.
For a typical no-change launch, /verify adds essentially no overhead. For a
/clean /verify recovery scenario where everything is being recopied, expect
the launcher to take noticeably longer (often 2-3x the normal recovery time)
because every file gets hashed.
When to use it¶
- A user is reporting application instability that smells like file corruption.
- After a known-bad disk or RAM event on the user's machine.
- As a confidence check after
/cleanwhen you really want to know the install is byte-perfect.
Example¶
Combined with /clean:
/skiplaunch¶
Run sync, but don't launch Pulse Dashboard.
The launcher does its full sync (and optional clean), then exits without starting the application. The Dashboard does not open.
When to use it¶
- Testing the launcher itself without booting the full application.
- Pre-staging the local install on a machine before the user logs in.
- Verifying that a sync succeeds without disrupting whatever the user is currently doing.
- Combined with
/showlogfor "I just want to see what would happen" runs.
Example¶
Combined with /showlog for a no-launch diagnostic:
/showlog¶
Open the log file after the launcher exits.
The log opens in whatever application is registered for .log files (Notepad
on most systems). It opens immediately as the launcher closes, so the launched
Pulse Dashboard window comes up beside the log.
When to use it¶
- Investigating any launcher behavior — slowness, errors, unexpected file copies, etc.
- Building a "diagnostic" shortcut for support staff to drop on a user's desktop.
- Confirming that flag changes (
/clean,/verify) actually took effect.
Example¶
A useful diagnostic combination — sync only, then show the log:
Combinations¶
Flags can be combined freely. Some particularly useful combinations:
| Combination | Use case |
|---|---|
/clean /verify |
Maximum-paranoia recovery: wipe, re-sync, hash-verify everything. |
/clean /yes |
Unattended recovery: wipe and re-sync without prompting. |
/clean /yes /verify /showlog |
Full recovery, no prompts, see the log. |
/skiplaunch /showlog |
Sync-only diagnostic: refresh files, view log, don't launch. |
Flag forwarding¶
The flags listed above are launcher-only — they're consumed by the launcher and not forwarded to Pulse Dashboard.exe. Any unrecognized arguments (typically things Pulse Dashboard itself uses) are forwarded as-is.
For example, this command:
The launcher consumes /clean, then launches Pulse Dashboard with arguments
remote /skipnav --user=jdoe — the Dashboard sees only the things meant for
it.