My API client desktop app will not open at all — no window, no error, just nothing. How do I find out why?

The corrupted-data one deserves the emphasis it is getting, but there is a sharper version of the fix worth knowing.

Rather than moving the whole directory, look inside it first. There is usually a distinct cache folder separate from the actual data. Clearing only the cache very often fixes the crash while leaving your collections, environments and history completely untouched — no export, no re-import, no signing back in.

So the ladder is: clear the cache subfolder, then the whole shell-managed cache, and only then move the entire directory aside.

Works the same way for basically every desktop app built on this stack, which by now is most of them.

A process that starts and exits within seconds with no window is a crash during startup, before the UI is created. That narrows it a lot, because only a handful of things run before the first window paints.

Get the actual error first. These apps are almost all built on a web-engine shell, and every one of them writes a log. Two ways in, in order of usefulness:

• Launch it from a terminal instead of the icon. The startup exception is very often printed to standard error and simply thrown away when you launch from the desktop. This one step solves most of these.
• Find the log directory. These shells use a conventional per-user application data location per operating system — an app-data folder on Windows, an application support folder on macOS, a config or share directory under your home on Linux. Look for a logs folder under the app's own directory there, sorted by modification time.

With the message in hand it is usually obvious. Without it, work through the four things that cause this, in this order:

1. Corrupted local application data. The overwhelming favourite, and it fits "worked yesterday, reinstalling did not help" exactly — because uninstalling does not remove the per-user data directory, so the reinstall dutifully loaded the same broken state. A partial write during a crash or an update leaves the cache or the local database inconsistent, and the app dies reading it.

The fix is to move that directory aside — rename, do not delete — and start the app. If it opens, you have your answer and you still have the old directory to recover data from.

2. GPU acceleration. A driver update, or a change of external monitor, and the shell crashes creating its rendering surface. Every one of these apps accepts a command-line flag to disable GPU acceleration; launch it once with that flag and see. If it opens, turn hardware acceleration off in its settings and it will keep working.

3. A proxy or TLS interception in the way. Many of these apps make a network call during startup — sign-in, sync, a licence check — and some handle a failure at that point very badly. On a corporate network with an intercepting proxy, the app cannot validate the certificate, the startup promise rejects, and nothing ever renders. Test on a different network, or on a phone hotspot, and if it opens you know.

4. Antivirus or endpoint protection. It quarantined part of the app or blocks its helper process. This produces exactly the silent instant exit. Check the protection software's quarantine log for the app's name — that is a thirty-second check that occasionally is the whole answer.

On getting your collections out, which is the actually urgent part: they are in that same per-user data directory, usually in a local database file. Before you do anything at all — before renaming, before reinstalling again — copy that entire directory somewhere safe. It is small. Then you can experiment freely.

If the app never opens again, the data is still recoverable from that copy: these local stores are usually a well-known embedded database format, readable with ordinary tools, and the requests are typically stored as documents you can pull out and reshape into an import file.

And if you had signed in and sync was enabled, your collections are on the server too and the fastest route back to working is the web version or a fresh profile.

Unblocking suggestion for right now, separate from the diagnosis: you do not need the desktop app to keep working.

Most of these tools have a browser version that reaches the same synced workspace, and there are command-line and editor-based alternatives that read a plain text file of requests. If you are blocked on a deadline, spend ten minutes moving the two or three requests you need rather than an hour on the crash.

The longer-term version of that: keeping your requests as a file in the repository, next to the code they exercise, means they are versioned with the API, reviewable in a diff, and immune to any single tool's local database going bad. I moved for exactly this reason after the second time this happened.

If it turns out to be the GPU path, check whether you had a monitor connected yesterday that is not connected now, or vice versa.

A surprising number of these startup crashes are the app trying to restore its window geometry onto a display that no longer exists. The window is created — off-screen, on a monitor that is not there — and then the process tidies itself up.

Deleting just the window-state file in the app data directory fixes that specific case without touching anything else.