ClipDiff for Windows

ClipDiff is a Windows notification-area utility that compares the last two text values captured after it starts. A value can come from copied Unicode text or from a file copied in Explorer.

ClipDiff listens to the Windows clipboard directly. No data is ever uploaded.

Use

1. Start ClipDiff.exe. It opens in the notification area
2. Copy the older text or file. Explorer's Copy as path, Visual Studio's Copy Full Path, and VS Code's Copy Path also count as copying an existing local file.
3. Either copy the newer text or file, or right-click the newer file in Explorer and choose Compare with current ClipDiff capture.
4. If you copied the newer value normally, press Ctrl+Alt+D (or your chosen replacement) or right-click the ClipDiff icon and choose Show Diff. The Explorer command opens the diff immediately.
5. You can also copy two files at the same time—or select exactly two files in Explorer and choose Compare two selected files with ClipDiff—to diff them immediately without an existing capture.

The built-in viewer is the default. Its reusable window opens in 'Side by Side' mode but can switch to 'Unified' or copy the unified difference as ordinary Unicode text. Closing the window hides it; Quit ClipDiff in the notification-area menu exits the application.

The menu's Diff viewer submenu lists supported programs found on the machine, provides Choose program... for another executable, and lets you return to the built-in viewer. The selection is remembered. Keyboard shortcut... opens a small recorder: click the capture box, press a combination containing Ctrl or Alt (with optional Shift), then choose Save. ClipDiff tests the replacement before releasing the current shortcut, reports conflicts in the recorder, and provides Reset to Ctrl+Alt+D. Windows-key shortcuts, mouse buttons, Alt+F4, and debugger-reserved F12 are not accepted. Enter saves, Escape cancels, and Tab/Shift-Tab move focus. Releasing an unfinished modifier combination restores the last complete draft. While the capture box has focus, pressing the active global shortcut records it rather than opening a diff. If saving fails, ClipDiff attempts to restore the previous shortcut and explicitly reports when that restoration also fails.

The menu also shows short previews of the current and previous entries, and provides an About ClipDiff window with project links. A file-backed entry always includes its filename before the preview. Monitoring stays active while ClipDiff is running; use Quit ClipDiff to stop it and discard captured text. If another application owns the configured shortcut, ClipDiff continues to work through its notification-area menu and labels the command Show Diff (shortcut unavailable).

Copied files

When Explorer places files on the clipboard, ClipDiff checks the same privacy markers used for ordinary text before obtaining any file paths. A standard file list takes precedence over any accompanying text.

Full paths copied as text, including Explorer Copy as path, Visual Studio Copy Full Path, and VS Code Copy Path, use the same file conversion. The complete text must contain one or two fully qualified Windows drive or UNC paths, one per line. Each path may independently have a matched pair of double quotes; spaces and Unicode in filenames are preserved. CRLF/LF separators and a trailing newline are accepted.

If any path is unquoted, every path must resolve to an existing file. A missing file, directory, or failed existence check leaves the entire original payload as ordinary text. Fully quoted paths retain Explorer's filename/reason fallbacks for missing files and directories. Lists of more than two valid existing files are ignored; fully quoted lists of more than two paths keep the existing ignore behavior. Relative or drive-relative paths, environment-variable expressions, URLs, remote editor URIs, line/column suffixes, malformed quoting, and paths mixed with prose or code remain ordinary text. ClipDiff neither expands variables nor repairs quotes.

ClipDiff reads the saved file when it processes the clipboard event; unsaved editor buffers are not included. Copying code directly continues to capture that code as text. File probes and reads run off the UI thread, including UNC access, and a newer clipboard update cancels pending work. If a recognized file disappears or becomes unreadable before the read, the usual filename/reason fallback applies. The Windows clipboard is unchanged.

Copying file nodes with Ctrl+C in Visual Studio Solution Explorer or VS Code Explorer is a separate workflow whose editor-specific clipboard formats have not been verified on a Windows desktop. Standard file lists are handled already; no adapter for custom project-item formats is included. WSL, SSH, container, browser, and virtual-workspace resources are not assumed to be Windows-local files.

A single copied file is converted as follows:

• .bat, .cmd, .ps1, terminal captures containing ANSI escape sequences, and other files whose bytes look like text contribute their full decoded contents. UTF-8, BOM-marked UTF-16/UTF-32, common BOM-less UTF-16, and Windows-1252 text are supported.
• Known binary executable/package types such as .exe, .com, .dll, and .msi contribute the filename with a reason, such as program.exe (binary file).
• Other binary-looking, empty, missing, unreadable, directory, or larger-than-16-MiB entries also contribute the filename with (binary file), (empty file), (file not found), (file unreadable), (directory), or (file too large) appended as appropriate.

Windows .lnk shortcuts also work: ClipDiff reads the saved contents of the stored target and shows the target filename. This applies to copied shortcuts, copied shortcut paths, and both Explorer comparison actions. Target files use the same encoding, binary, size, and fallback rules as ordinary files. ClipDiff does not launch the shortcut, use its arguments, search for moved targets, or modify the shortcut. Invalid or non-file shortcuts fall back to the shortcut filename with (file unreadable); chains stop after eight shortcuts or at a cycle. Shortcut loading runs off the UI thread and newer captures supersede it.

The decision uses both safe binary-extension handling and content inspection, so a binary renamed to .txt still falls back to its filename.

ClipDiff retains the source basename separately from the converted text. The filename is always shown on the corresponding side of the built-in diff, in unified/copied diff headers, in the notification-area current/previous item, and in external-viewer labels. If both sides have the same filename but come from different paths, ClipDiff adds only enough parent directories to distinguish them—for example, branch-a/src/settings.json and branch-b/src/settings.json.

The full source paths are retained only in the same two-entry in-memory history as the captured values so ClipDiff can calculate those labels. The diff document keeps the resolved labels but drops the original paths. Paths are never logged, stored in settings or the Explorer registration, or reproduced in the external-viewer temporary workspace. Evicting or clearing an entry, or exiting ClipDiff, discards its retained path.

When exactly two files are copied together, ClipDiff converts each one independently and immediately uses them as the comparison pair: the first clipboard path is Previous and the second is Current.

While clipboard monitoring is active, selecting exactly two files in Explorer also offers Compare two selected files with ClipDiff. It converts both files with the same rules, atomically replaces the current comparison pair, and opens the configured viewer. Explorer's first supplied path becomes Previous and its second becomes Current. No prior capture is needed, and the Windows clipboard and ClipDiff's clipboard sequence baseline are unchanged.

After ClipDiff has captured at least one value, and while clipboard monitoring is active, it adds Compare with current ClipDiff capture to the Explorer context menu for individual files. If the current capture came from a file, the command appends that filename so the comparison source is visible before it is invoked. Choosing it reads the selected file with the same conversion rules, promotes that result to Current, moves the former Current entry to Previous, and immediately uses the normal Show Diff workflow. It does not change the Windows clipboard. On Windows 11, this classic context-menu command may appear under Show more options.

Both context-menu registrations are per-user, require no administrator access, and use classic Explorer verbs, so Windows 11 may place them under Show more options. The two-file command appears only when exactly two files are selected and ClipDiff is running and monitoring; the individual-file command additionally requires a usable current capture. Losing the last capture removes the individual-file command; quitting removes both when no other live session needs them. Concurrent sessions for the same user coordinate the shared registrations. Their individual-file label is generic because the registry is shared, while invocation validates the capture in the local session. A later ClipDiff start cleans up registrations left by an abnormal exit. Coordination retries brief lock contention; if a peer stays stalled beyond the retry deadline, the surviving instance reconciles registration on its next capture update or tray-menu opening.

The two-file command uses a small native ClipDiff.ShellExtension.dll beside the executable. Its Shell initialization interface receives the complete selection, so it can show the command only for two files. It checks Shell metadata without reading file contents, then forwards the selection data object to ClipDiff's existing out-of-process COM drop target when clicked. Selected paths never appear in a process command line or the registry. The DLL holds the selection only for the menu's lifetime; file conversion and comparison run in ClipDiff. A memory-only readiness event keeps cached menus inactive after ClipDiff has exited.

A newer Explorer request or accepted clipboard value cancels pending selected-file work. The single-file command checks that its original capture is still current when the read finishes. Slow reads and incomplete pipe messages do not block receipt of newer commands; failed forwarding gives concise feedback.

Copies containing more than two files are ignored; ClipDiff never creates a comparison value from a file list.

File contents and paths are never written by these built-in workflows; the resulting value or pair follows the same two-entry, in-memory history policy as copied text. For the individual-file command, Explorer necessarily supplies the directly selected file path to a short-lived ClipDiff process. ClipDiff forwards it to the existing tray process over a same-user, per-session local pipe. For the two-file command, Explorer marshals the selection directly to the running ClipDiff process. In both cases, each path is retained only with its in-memory entry for collision disambiguation; it is never logged or persisted.

For large comparisons, Myers line matching uses at most 8 MiB of frontier/trace integer payload and 2,000,000 search steps. When that budget is reached, ClipDiff preserves exact common leading/trailing lines and pairs the remaining block by position. All text and line numbers remain available, though matching lines inside that block may appear as changed. Document storage still grows with the number of input lines.

External diff viewers

ClipDiff has command-line profiles for these developer tools:

• SourceGear DiffMerge
• WinMerge
• Meld
• KDiff3
• Beyond Compare
• Araxis Merge
• Visual Studio Code
• Visual Studio
• TortoiseGitMerge
• TortoiseMerge
• P4Merge
• ExamDiff Pro

ClipDiff checks Windows App Paths, PATH, installer registry entries, known vendor registry entries for WinMerge and Beyond Compare, and the programs' usual machine-wide and per-user install locations, including %LOCALAPPDATA%\Programs. Registry discovery checks the current-user and machine registrations in both 32-bit and 64-bit views, so a supported viewer can be found in a custom directory when its installer records that location. Missing executables and unreadable or malformed registrations are ignored. Detection lists available viewers without selecting one automatically.

A portable viewer without a registered location or PATH entry can be selected with Choose program.... The executable is matched to a known profile by name; an unknown executable receives the previous and current file paths as two positional arguments. If no external viewer is selected, its executable is no longer available, or it cannot be started, Show Diff falls back to the built-in viewer.

Privacy model and limitations

ClipDiff captures only future, non-empty text values (including the copied-file conversion above) and retains at most two accepted values in process memory. Consecutive copies of identical text are accepted as separate entries, allowing ClipDiff to report No differences. Unsupported non-text clipboard changes do not alter the entries. Quitting discards the in-memory entries and active diff without changing the Windows clipboard. ClipDiff never logs, uploads, or transmits captured text or file contents.

The built-in viewer keeps captured text in memory only. An external program cannot compare in-memory strings directly, so selecting an external viewer creates an explicit exception: after a one-time warning is accepted, ClipDiff writes the two values as UTF-8 plaintext files in a unique directory below %LOCALAPPDATA%\ClipDiff\Temp. Ordinary text uses Previous clipboard.txt and Current clipboard.txt; file-backed values use their source basename within separate Previous and Current child directories so even positional-only viewers expose the filename. The files are marked read-only. ClipDiff attempts to remove that directory after the launched process exits, when ClipDiff exits, and during its next startup.

This cleanup is best effort. A crash, power loss, open file handle, or external viewer that hands work to another process can leave files behind, and the selected program may cache or retain its own copy outside ClipDiff's control. Do not select an external viewer when this disk exposure is unacceptable. Cancelling the warning opens the built-in viewer without writing the files. If automatic privacy clearing or a newer comparison invalidates the saved pair while the warning is open, neither OK nor Cancel reopens or exports it.

ClipDiff stores only the selected executable path, the one-time-warning acknowledgement, the chosen shortcut's modifier/key codes, and whether the login prompt has been shown in %LOCALAPPDATA%\ClipDiff\settings.json; clipboard text and previews are never stored there. Rebuilding or replacing the executable does not reset the acknowledgement. To retest the notice, close ClipDiff and set PlaintextWarningAcknowledged to false in that file; the selected program can remain unchanged. With the built-in viewer, normal exit loses all captured content. With an external viewer, normal exit also attempts to remove this instance's temporary comparison directories. Empty exclusive owner leases protect live workspaces in another session from startup cleanup; leases contain no captured text. Shared Explorer registration claims contain only executable/DLL commands and menu metadata, and stale claims are removed at startup.

Before reading text, ClipDiff inspects and honours these advisory clipboard formats:

• ExcludeClipboardContentFromMonitorProcessing
• CanIncludeInClipboardHistory when its DWORD is zero
• CanUploadToCloudClipboard when its DWORD is zero

Malformed or unreadable privacy markers are excluded conservatively. Copy unified diff writes its Unicode text and all three exclusion formats in one native clipboard operation, and ClipDiff suppresses the resulting clipboard update.

Some password managers clear an unmarked value shortly after copying it. If an accepted value is immediately followed by an explicit clipboard clear within 60 seconds, ClipDiff removes that current entry. An intervening unrelated, sensitive, or failed clipboard observation cancels this eligibility. This is only a best-effort heuristic and does not come with a guarantee.

Important limitations:

• Copying a text-like file intentionally causes ClipDiff to read that file from disk and retain its decoded contents in process memory.
• A file-backed entry's full source path is retained in memory until that entry is evicted, cleared, or lost on exit; only the shortest distinguishing suffix is displayed when filenames collide.
• Passwords without standard privacy markers are indistinguishable from ordinary text.
• The automatic-clear heuristic cannot identify every sensitive value or clearing pattern.
• .NET strings cannot be guaranteed to be securely zeroed in memory.
• Operating-system paging, process dumps, other clipboard monitors, and Windows clipboard history are outside ClipDiff's control.
• Temporary plaintext and any copies retained by a selected external diff program are outside the memory-only guarantee described above.

ClipDiff does not guess whether text is sensitive from its length, punctuation, entropy, apparent source process, or token-like appearance.

Requirements

• Windows 10 version 1809 or newer, or Windows 11
• Windows Server 2022 with Desktop Experience
• An interactive desktop session with a clipboard and notification area

Windows Server Core is not supported. The initial release target is win-x64.

Install or update

Download one of these assets from the GitHub release and extract the whole archive into its own directory:

• ClipDiff-<version>-win-x64-self-contained.zip includes its own .NET runtime and works without a separately installed runtime. It is the larger download.
• ClipDiff-<version>-win-x64-net10.zip is much smaller but requires the x64 .NET 10 Desktop Runtime (Microsoft.WindowsDesktop.App), not merely the base Microsoft.NETCore.App runtime.

Check an existing installation with dotnet --list-runtimes; the smaller build requires a Microsoft.WindowsDesktop.App 10.x entry for x64. Both archives contain exactly these two files:

ClipDiff.exe
ClipDiff.ShellExtension.dll

They must stay beside one another. Run ClipDiff.exe; the application manages the Explorer integration per user. Do not copy the DLL to a Windows system directory or register it manually.

ClipDiff is portable and has no installer. The directory may be anywhere the current user can write, for example %LOCALAPPDATA%\Programs\ClipDiff\1.0.0. To update, quit ClipDiff, extract the new ZIP to a new directory, and run the new executable. Using a new directory avoids trying to overwrite an older shell-extension DLL that Explorer may still have loaded. Restarting Explorer or signing out may be needed before the old directory can be deleted.

Build and test

Prerequisites on Windows

1. Install the .NET 10 SDK (not only the .NET Desktop Runtime) from the .NET 10 download page. Alternatively, install it through Visual Studio Installer by selecting the .NET desktop development workload in a Visual Studio version that supports .NET 10.

2. Open a new PowerShell window after installation and confirm that a 10.0.x SDK is available and selected:

   dotnet --list-sdks
   dotnet --version

   If dotnet --version does not start with 10., update/install the SDK before continuing. Installing only a runtime is not sufficient to build ClipDiff.

3. Clone the repository (or open PowerShell in an extracted source directory), then change to the directory containing ClipDiff.Windows.sln.

Build from PowerShell

Restore packages, run all automated tests, and compile a Release build:

dotnet restore ClipDiff.Windows.sln
dotnet test ClipDiff.Windows.sln --configuration Release --no-restore
dotnet build ClipDiff.Windows.sln --configuration Release --no-restore

The framework-dependent developer executable is then at src\ClipDiff.Windows\bin\Release\net10.0-windows10.0.17763.0\ClipDiff.exe. It requires the .NET 10 Windows Desktop Runtime on the computer where it runs. It is not the distributable package. For the self-contained, validated two-file package, use the local release script below instead.

The pure ClipDiff.Core project and its tests target ordinary net10.0, so they can run on macOS:

dotnet test tests/ClipDiff.Core.Tests/ClipDiff.Core.Tests.csproj

ClipDiff.Windows.Tests targets Windows and references the WPF application; run the complete Windows suite on Windows.

The Windows project has EnableWindowsTargeting=true, which permits cross-compilation where Microsoft targeting packs are available. A successful macOS compile is not a functional Windows test. Clipboard formats, notification-area behaviour, global hotkeys, WPF presentation, and native cleanup still require Windows verification.

Build the native menu extension on Windows with Visual Studio C++ build tools (the Desktop development with C++ workload and a Windows SDK):

./scripts/build-shell-extension.ps1 -Test
dotnet build ClipDiff.Windows.sln --configuration Release

The .NET build copies the built DLL beside the application. The native tests ask Windows to construct the context menu using real Shell selections, then verify visibility and COM delivery. They use temporary registry keys and test files, and require ClipDiff to be closed. Run the build/release scripts from a normal, non-administrator PowerShell window. If launched as administrator with UAC, the tests restart using Windows' linked unelevated token; on CI accounts without a linked token, they create a restricted test child. Both the launch token and child are checked for elevation before Shell tests run. They do not change UAC or account settings. The two-file Explorer menu is unavailable when the DLL is missing; clipboard and tray comparison remain available.

An older test launcher could print elevated=0, elevationType=2 after dropping privileges. Type 2 still identifies a full UAC token, so that child did not reproduce a normal unelevated Shell process. The linked-token restart must report elevated=0, elevationType=3. If an older build fails menu discovery in the former state, rerun from non-administrator PowerShell or rebuild with the corrected launcher.

If the native test run fails, include the full output from Native build: through the final [FAIL] line and script error. The output identifies the test case, expected visibility, direct-handler and Windows-aggregate results, HRESULT/Win32 errors, selection counts and Shell attributes, and effective COM/menu registration. A visibility mismatch also prints menu IDs, states, separator labels, and a read-only snapshot of Shell restriction settings and ClipDiff's Approved/Blocked entries. These probes do not change policy or read clipboard contents or selected file paths. Passing the direct-handler check but failing the Windows-aggregate check narrows the problem to Shell discovery/aggregation; it does not by itself establish that a work-machine policy is responsible. Microsoft's Shell extension approval policy documentation explains one possible restriction.

GitHub Actions runs the same release script on windows-latest for every push and pull request. It checks regular and prerelease tag versions, assembly metadata, and asset names on every run. A v1.2.3 or v1.2.3-preview.1 tag publishes both validated ZIPs using that same version. Each successful run provides ClipDiff-win-x64-self-contained and ClipDiff-win-x64-net10 artifacts. Each contains only the executable and native DLL; extract both into the same directory. The workflow can be run manually from the repository's Actions tab as well. Actual Explorer desktop interaction remains a separate manual check.

Local release

On Windows PowerShell, from the repository root:

.\scripts\create-local-release.ps1

The script builds and tests the native extension, runs the .NET tests, and publishes self-contained and framework-dependent, untrimmed win-x64 applications. It stages each variant in a clean private directory, then creates these gitignored directories and ZIPs:

releases\ClipDiff-<version>-win-x64-self-contained\
releases\ClipDiff-<version>-win-x64-self-contained.zip
releases\ClipDiff-<version>-win-x64-net10\
releases\ClipDiff-<version>-win-x64-net10.zip

Both directories and ZIPs are validated to contain exactly ClipDiff.exe and ClipDiff.ShellExtension.dll. Those are the complete release; keep them together. The self-contained variant bundles .NET; the net10 variant expects the x64 .NET 10 Desktop Runtime on the target computer. PDB, deps.json, runtimeconfig.json, bin, obj, and the rest of the raw publish directories are not release payload. Pass -Launch to start the self-contained packaged executable after publishing. The personal builds are unsigned, so Windows SmartScreen may warn before first launch.

To skip the native Explorer integration tests for a local release, pass -SkipNativeTests:

.\scripts\create-local-release.ps1 -SkipNativeTests

This still builds and packages the native DLL and runs the .NET tests. Native tests run by default and remain enabled in CI. You can combine this switch with -Launch.

Quit ClipDiff before upgrading. The versioned package directory deliberately makes side-by-side extraction straightforward because Explorer may keep the old DLL loaded. Restart Explorer or sign out if the old handler remains loaded. Starting the new version removes the obsolete two-file static menu registration automatically.

If PowerShell reports that script execution is disabled, allow the checked-out script for this process only, then run it again:

Set-ExecutionPolicy -Scope Process Bypass
.\scripts\create-local-release.ps1

Copy the chosen ZIP to the target PC and extract both files together. Choose the net10 archive only when the x64 .NET 10 Desktop Runtime is already installed.

No installer, automatic updater, or code signing is included in the initial release.

Maintainer instructions for publishing a tagged GitHub release are in RELEASING.md.

Windows verification checklist

For repeated clipboard activity and process-resource counters, use the standalone C# stress tool. It writes generated text, single files, file pairs and copied paths to the clipboard, then samples a cooldown. It does not change the ClipDiff application or collect clipboard contents.

On a Windows desktop, verify:

• only one notification-area icon appears and a second process exits cleanly;
• clipboard text that existed before startup is not captured;
• two future text copies, including identical text, or one exact-two-file copy produce Ready to diff and Ctrl+Alt+D opens the window;
• side-by-side rows remain aligned, unified output is exact, and long lines wrap;
• copied and directly selected files show their source filename in the tray item and on the corresponding diff side, including unified output and external viewers; equal filenames from different paths use the shortest unique suffix;
• the view dropdown is readable closed and open, including hovered/selected items; Tab, arrow keys, Enter, Escape, and Alt+Down still operate it;
• neither the tray nor the viewer exposes a clear command, and the tray has no monitoring toggle;
• the built-in viewer is selected by default, detected external programs appear under Diff viewer, and Choose program... accepts another executable;
• selecting an external viewer shows the privacy warning once; cancelling uses the built-in viewer without creating plaintext files;
• clearing a recent clipboard value while that warning is open prevents both OK and Cancel from exporting or reopening the saved pair;
• a slow Explorer request cannot overwrite a newer completed pair, and copying a newer capture during a single-file request cancels that request;
• in two concurrent sessions for the same user, starting and quitting B preserves A's active external comparison files and Explorer commands;
• each supported installed viewer receives the previous/current sides in the right order and with the documented labels and read-only switches where supported;
• external comparison files appear only below %LOCALAPPDATA%\ClipDiff\Temp, contain the exact text, and are removed after the launched process exits, on ClipDiff exit, or on the next start;
• removing or renaming the selected viewer executable causes Show Diff to fall back to the built-in viewer;
• %LOCALAPPDATA%\ClipDiff\settings.json contains only the executable preference, warning acknowledgement, shortcut codes, and the login-prompt flag, never clipboard content;
• Keyboard shortcut... records a replacement such as Ctrl+Alt+6, keeps the old shortcut active when the replacement is already in use, updates the tray label after success, persists across restart, and resets to Ctrl+Alt+D;
• Copy unified diff pastes into Notepad, has all three exclusion formats, and is not recaptured;
• two identical copies produce a diff reporting No differences, while images leave history unchanged;
• a copied .bat contributes its full text, a copied .exe contributes its filename plus (binary file), and a renamed binary is still treated as binary;
• a copied .lnk shortcut reads its saved target contents and shows the target filename, including shortcut/file pairs and both Explorer actions; broken or invalid targets fall back without launching anything or changing the shortcut;
• exactly two copied files—or two files copied with Explorer Copy as path—become the previous/current comparison pair in clipboard order, while copies of more than two files are ignored; missing, unreadable, empty, directory, oversized, and binary entries fall back to a filename with the reason appended;
• after one capture, right-clicking a second file offers Compare with current ClipDiff capture (including the current filename when file-backed), makes that file the new current entry, and immediately opens the selected diff viewer without changing the clipboard;
• selecting exactly two Explorer files offers Compare two selected files with ClipDiff without requiring a prior capture, makes the first Shell-supplied path previous and the second current, and immediately opens the selected viewer without changing the clipboard;
• selecting one file, three or more files, folders, or a mixture of files and folders hides the two-file command; invalid invocations do not alter history or cause file reads;
• quitting removes both Explorer commands, and Windows 11 exposes classic commands under Show more options when they are not in the primary menu;
• closing the diff window leaves the tray application running;
• occupying Ctrl+Alt+D leaves Show Diff usable from the menu;
• a privacy-marked item is not read, and a recent unmarked value followed by a clear is removed;
• quitting removes the icon, unregisters native resources, and loses all captured content.

Run the same checks through Remote Desktop if Windows Server 2022 is the intended host.

Optional start at sign-in

ClipDiff asks once on its first normal launch whether it should start automatically when you sign in to Windows. Both Yes and No dismiss future prompts. Existing users see the question once after upgrading. Change the choice at any time using Start at login in the notification-area context menu.

Enabling this registers the quoted executable path in the current user's HKCU\Software\Microsoft\Windows\CurrentVersion\Run key; no administrator access is required. The check mark reflects that registration. Windows Startup Apps/Task Manager can separately disable it; re-enable it there if necessary. Disabling the menu option removes ClipDiff's Run value, and quitting the app leaves the registration intact.

After extracting an update to a new directory, run the new executable once: an existing registration is updated to that location. Remove any shortcut you previously added to shell:startup; the toggle does not manage manual shortcuts.

ClipDiff still captures only values copied after it starts.

Windows verification:

• Answer No, restart, and confirm the question does not return.
• Enable Start at login, sign out/in, and confirm one tray instance starts.
• Disable it, sign out/in, and confirm ClipDiff does not start.
• Answer Yes on a fresh profile and verify the same login behaviour.
• Launch an update from a path containing spaces and confirm login uses it.
• Check that registry/settings write failures produce a warning and no false check mark.