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

"\\server\share\Pulse Dashboard Client.exe" /clean

/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

"\\server\share\Pulse Dashboard Client.exe" /clean /yes

/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 `/clean` when you really want to know the install is byte-perfect.

Example

"\\server\share\Pulse Dashboard Client.exe" /verify

Combined with `/clean`:

"\\server\share\Pulse Dashboard Client.exe" /clean /verify

/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 `/showlog` for "I just want to see what would happen" runs.

Example

"\\server\share\Pulse Dashboard Client.exe" /skiplaunch

Combined with `/showlog` for a no-launch diagnostic:

"\\server\share\Pulse Dashboard Client.exe" /skiplaunch /showlog

/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

"\\server\share\Pulse Dashboard Client.exe" /showlog

A useful diagnostic combination — sync only, then show the log:

"\\server\share\Pulse Dashboard Client.exe" /skiplaunch /showlog

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:

"...Pulse Dashboard Client.exe" /clean /skipnav --user=jdoe

The launcher consumes `/clean`, then launches Pulse Dashboard with arguments `remote /skipnav --user=jdoe` — the Dashboard sees only the things meant for it.