Windows Super God Mode: a PowerShell script that builds a shortcut folder for every Windows special location

What Windows Super God Mode actually produces

The project descends from the old God Mode trick, a folder whose name embeds a CLSID so Explorer renders a control panel listing. ThioJoe's script keeps that idea and widens it. According to the README, it creates shortcuts to all special shell folders, named folders, task links, system settings, deep links and URL protocols, and the author notes it "creates many more shortcuts than even that." The output is a folder of .lnk files, plus CSV files describing them and XML content pulled from shell32.dll and other sources kept for reference.

The audience is narrow but real. Anyone who documents Windows builds, writes deployment scripts, or supports users over the phone benefits from a single directory where ms-settings: pages and internal app links sit next to each other. The README is explicit that the tool does not alter the system: "Running this doesn't change any system settings, it just creates a folder containing a ton of shortcuts." Treat it as a reference generator, not a tweaker.

How the script harvests CLSIDs, task links and URL protocols

The mechanism visible in the README is extraction from Windows binaries rather than hardcoded lists. The script reads shell32.dll and other sources, saves the retrieved XML, and turns string references into readable shortcut names. Category arguments map directly onto the data sources: -SkipCLSID, -SkipNamedFolders, -SkipTaskLinks, -SkipMSSettings, -SkipDeepLinks, -SkipURLProtocols and -SkipHiddenAppLinks each disable one harvest pass.

Task links are the sub-pages nested inside shell folders and control panel menus, and the script can group them by application name unless -DontGroupTasks is passed. Hidden app links are described as internal-use and undocumented URL links used by apps; -DeepScanHiddenLinks extends the search to every file in a non-appx app's install directory instead of only the main binary. That flag is the clearest signal of the cost model: broader scanning means more file reads. -debugSkipAppxSearch exists to skip AppX packages entirely, which is the escape hatch when the scan is slow or noisy. -CollectExtraURLProtocolInfo and -AllURLProtocols widen URL protocol collection beyond what Windows ships, pulling in protocols registered by installed third-party software.

Installing and running Windows Super God Mode for the first time

There is no installer and no package manager entry. The README points to two downloads from the releases page: Super_God_Mode.ps1 and SuperGodMode-EasyLauncher.bat. Option 1 places both files in the same folder and runs the batch file. Option 2 skips the launcher and starts the script from PowerShell. The README's direct link for the script is https://github.com/ThioJoe/Windows-Super-God-Mode/releases/latest/download/Super_God_Mode.ps1.

Open a terminal in the folder holding the script and run it with the execution policy bypassed for that process only:

powershell.exe -ExecutionPolicy Bypass -File ".\Super_God_Mode.ps1"

With no parameters, the README states a GUI appears for configuration. Every setting in that dialog is optional and the script runs with defaults if nothing is changed.

The CLI path is more useful for repeatable runs. The README's own example sends output to a fixed folder, enables third-party URL protocols and turns on verbose logging:

.\Super_God_Mode.ps1 -Output "C:\SuperGodMode" -AllURLProtocols -Verbose

The README carries a rule that trips people up: except for -Debug and -Verbose, arguments only take effect when -NoGUI is also supplied. So a headless run that keeps the default categories looks like this:

.\Super_God_Mode.ps1 -NoGUI -Output "C:\SuperGodMode" -KeepPreviousOutputFolders

After the run, expect a folder of shortcuts plus a statistics folder and a tips text file, unless -NoStatistics or -NoReadMe suppress them. Output folders from previous runs are deleted first by default; -KeepPreviousOutputFolders prevents that, and the README lists uniqueOutputFolder as a way to append an identifier to the folder name so an existing folder is not overwritten.

Where the script falls short, and when it is the wrong tool

The README's own notes admit that "some shortcuts may not work on all Windows versions due to differences in available features." That is the honest version of a bigger problem: the script harvests from the machine it runs on, so the output is a snapshot of that build, not a portable catalogue. A folder generated on one Windows 11 release may contain links that resolve differently or not at all on another build, and the README offers no compatibility matrix.

Two other constraints matter. First, the tool is a generator, not a manager: it does not track which shortcuts you use, and re-running it with default settings deletes the previous output folder, so any manual curation inside that folder is lost unless -KeepPreviousOutputFolders is set. Second, the deep scan flags trade runtime for completeness. -DeepScanHiddenLinks walks files in install directories, and -AllURLProtocols pulls in protocols registered by third-party software, which means the output can include entries for applications you may later uninstall. If you only need the classic God Mode control panel, the CLSID folder trick still works and needs no script at all; this project is for people who want the wider set.

How this differs from God Mode and from shortcut managers

The classic God Mode folder is a single directory with a magic name. It is instant, needs no script, and shows control panel items. Windows Super God Mode covers a different surface: ms-settings: links, task links, deep links, URL protocols and hidden app links, none of which the classic folder exposes. The README is careful about the word itself, noting "It's not really a 'mode', that's just a catchy name."

Compared with general shortcut or launcher utilities, the difference is data provenance. A launcher utility stores shortcuts you create by hand. This script derives them from shell32.dll, SystemSettings.dll and AppX packages, which is why it ships helper tools such as Get_DLL_String_Reference.ps1 for resolving a single @dllpath,-resourceID reference and Windows_XML_String_Resolver.ps1 for resolving whole XML files. Those helpers are the part a general launcher has no equivalent for, and they are also the part that makes the output version-dependent.

Licence, signatures and the cost of keeping up

The repository is licensed GPL-3.0, and the README states that release versions are signed with an EV code signing certificate. That signature applies to release binaries, not to a copy you edit, so a modified script loses the property that makes the download trustworthy. The GPL-3.0 terms govern redistribution; if you ship the script inside a product, read the licence text in the repository rather than assuming permissive terms. Nothing here is legal advice.

Maintenance is uneven. The last push to main was on 2026-06-02, which carried release v1.2.3. The release before it, v1.2.2, is dated 2024-08-29, so the gap between those two versions is roughly twenty-one months. Plan for long stretches without updates, and expect that new Windows builds may add settings the script does not yet harvest. Upgrading means downloading the script again and re-running it; there is no update mechanism in the README. Advanced flags such as -CustomDLLPath, -CustomLanguageFolderPath, -CustomSystemSettingsDLLPath and -CustomAllSystemSettingsXMLPath let you point the harvest at different binaries, which is the documented route if a future Windows version moves the data the script reads.

Editorial conclusion

Adopt it if you administer Windows machines and want a browsable map of shell folders, ms-settings pages and URL protocols without hunting through the registry, and if you are comfortable running an unsigned-by-default PowerShell script with -ExecutionPolicy Bypass. Do not adopt it if you expected a settings toggle: the README states the script does not modify system settings, and the name is only a nickname. Before running, verify the release asset hash and the EV signature, and check whether any shortcuts you depend on are missing, since the README notes that some shortcuts may not work on all Windows versions.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes