It won't even start

01The quick table

02"You must install .NET to run this application"

Here's the thing: you shouldn't be seeing this at all. The official release zips are self-contained — the .NET runtime is baked in, which is the whole reason the Docker recipe and every guide on this site skip runtime installation entirely. Seeing this error means you're holding the wrong artifact: usually the ancient NuGet dotnet tool package (stuck on a version from years ago — our installation page warns against it), a framework-dependent build from somewhere unofficial, or a rehosted exe of unknown parentage — which is its own red flag.

The fix is not to install .NET; it's to download the right thing: the platform zip from the official releases, or winget install --exact --id SteamRE.DepotDownloader on Windows, or brew tap steamre/tools && brew install depotdownloader on macOS. If you're deliberately running a framework-dependent build (you'd know), then yes — current .NET runtime, but you're off the paved road.

03Linux & macOS: the execute bit and the quarantine

Permission denied right after unzipping is the most universal first-run stumble on Unix-likes: zip archives don't reliably carry the execute permission, so the binary lands inert (issue #561 is the upstream conversation about exactly this). One line, once:

macOS adds a second gate. Anything downloaded by a browser carries the quarantine attribute, and Gatekeeper answers with "cannot be opened because the developer cannot be verified" or the even less helpful "is damaged and can't be opened". The binary is fine; the flag is doing its job on an unsigned tool. Clear it after you've confirmed the download came from the official repo:

Or sidestep both gates at once — the Homebrew route (brew tap steamre/tools) installs an executable, unquarantined binary in one move, which is why the installation page recommends it for Macs.

dotnet: command not found / ICU errors (Linux). These only hit the framework-dependent build — the one that needs .NET installed separately. The classics: command not found (the runtime isn't on your PATH, a frequent state after a reboot on Raspberry Pi and minimal distros) and Couldn't find a valid ICU package / a missing libicu (Ubuntu 24.04 and some Fedora versions ship an ICU the runtime doesn't expect). You can chase the distro-specific apt/dnf fix — or skip the entire class of problem by using the self-contained release zip, which bundles the runtime and has no .NET, PATH or ICU dependency at all. On Linux that's almost always the right answer — it's the only build I run on my own boxes precisely so I never have to think about ICU again.

Unhandled exception … Too many open files (macOS). On large downloads macOS can hit its low default file-descriptor limit, surfacing as a "too many open files" crash mid-run (issue #240, fixed in later builds). If you're on an old version, update first; if it persists, raise the limit for the session with ulimit -n 4096 before launching.

04Windows oddities

The flash-and-vanish. Double-clicking DepotDownloader.exe opens a console that closes before you can read it. Nothing crashed — it printed usage help and exited, because it's a command-line tool with nothing to do. Open Terminal/PowerShell, cd to the folder, and run it with arguments. (If you'd genuinely rather not live in a terminal, that's what the GUI is for.)

"-app is not recognized as the name of a cmdlet." The signature PowerShell stumble: you pasted the command but left off the leading .\. PowerShell won't run an executable in the current folder by bare name — it has to be .\DepotDownloader.exe -app …. (Plain cmd doesn't need the prefix, which is why copy-pasted commands work in one shell and not the other.) And if a path you pass — -dir, -filelist, your password — contains spaces, wrap it in quotes: -dir ".\My Games\old build". Unquoted spaces get read as separate arguments, which is a whole category of "it ignores my setting" confusion.

SmartScreen. "Windows protected your PC" on first run is reputation-based screening of an unsigned tool, not a malware verdict. The correct response order matters: first confirm your download really came from github.com/SteamRE/DepotDownloader — this prompt is the right moment for that paranoia, since rehosted clones are the actual threat in this ecosystem — then "More info → Run anyway". If Defender quarantines the file outright, restore it and add an exclusion only after the same source check. The full story on antivirus false positives — why they happen, how to verify with VirusTotal, and the misinformation that DepotDownloader.exe is a "Valve Source SDK" file — is on is DepotDownloader.exe a virus?

Non-ASCII paths. The long tail of weird Windows failures — downloads erroring on specific files, configs not persisting — has historically traced back to accented, Cyrillic or CJK characters in the download or install path. It's unglamorous advice, but it ends the mystery: point -dir somewhere like C:\depots\game and keep the whole path plain ASCII.

05Termux

Android earns one paragraph here and a full guide of its own. The two platform traps worth repeating: the Play Store Termux is frozen and broken for this purpose — F-Droid or GitHub builds only — and downloads can't reach shared storage until you run termux-setup-storage and grant the permission. Everything else (PRoot, wake locks, the wrapper's flag-order quirk) is in the guide.

Launched fine but failing after that? Then it's not this page: logins are the decoder table, 401s are the request-code tree, timeouts are network weather, and a wall of red ending in a .NET stack trace is the crashes & exceptions diagnostic. And install-from-scratch instructions for every platform live in the installation docs.