Most "portable" software still isn't actually portable — it writes config files to %APPDATA%, drops a cache somewhere in the user profile, or registers itself in the Windows registry even when you run it from a flash drive. For Pocket Core AI's USB Ghost Mode, none of that was acceptable, because the entire feature only means something if it's verifiably true, not just technically true.
Here's the actual constraint I built against: after unplugging the drive, a full-machine search for any trace of the app returns zero results, and a Process Monitor log filtered to the host drive (excluding the USB drive itself) shows zero write operations for the entire session, no matter how long the app ran or what was done in it.
What that ruled out:
Any use of the OS temp directory for anything that outlives the process — had to redirect all temp file handling to a path on the USB drive itself, not the system default
Any registry writes on Windows — no install-time registration, no "recently used" entries, nothing Electron's default userData path, which normally lives in the user profile — repointed to the drive
Any local model cache falling back to a system-wide location — voice models, embeddings, everything reads and writes only from paths under the drive's own root
What that required:
Explicit app.setPath() overrides for every Electron-managed path (userData, cache, temp, logs) before any other initialization code runs
Auditing every dependency (the TTS engine, the local model runtime) for its own default cache/config behavior — several assume a writable home directory exists and fail silently if you don't redirect them first
A startup check that fails loudly rather than falling back to a default path if the drive itself isn't writable, so there's never a silent "oh, it wrote to C:\ instead" failure mode
How it's verified, not just claimed: every public demo of this feature ends with the actual test — full-machine search post-unplug, Process Monitor log across the session, both run live on camera rather than described. That verification step turned out to matter more to actual buyers than the technical achievement itself; the professionals this feature is built for (security consultants, people under NDA-heavy client work) don't take portability claims at face value and shouldn't.
If you're building something that claims to be portable, the test I'd suggest: don't trust your own assumptions about what "portable" frameworks handle for you by default. Redirect every path explicitly, then verify with the same tools a skeptical user would use.
If you want to see the actual test run live (including on a machine I don't own), I posted the full video here:
