What 404 changes

The desktop app coordinates host changes so a browser can use the local STATIC proxy. These are separate pieces: CA trust lets the browser accept intercepted HTTPS; proxy routing sends requests to the engine; Windows WSL2 hosts the managed runtime. The details below reflect the published desktop guide. They have not been independently confirmed against the private desktop app source.

CA settings

STATIC generates and retains the local CA signing key. The app installs the public root certificate into host trust. The existing desktop guide says Windows uses LocalMachine\Root and macOS uses the login and System keychains; Firefox may require its own certificate trust setting. The key’s storage backend depends on where STATIC runs: the WSL2 process uses a Linux file path, so a filename ending in .dpapi there does not mean Windows DPAPI protected it. CA and trust traces the actual STATIC code.

To reverse trust, stop routing, use the app’s CA removal or cleanup flow, and check the host/browser stores where this root was installed. A fresh CA requires fresh trust. Do not delete only the public certificate or only the private key from STATIC’s managed state; mismatched state can prevent startup.

Proxy settings

When routing is enabled, the app points supported traffic at the local STATIC listener, documented as 127.0.0.1:4040 for the managed runtime. The existing guide describes Windows current-user Internet Settings (ProxyEnable, ProxyServer, ProxyOverride) and WinHTTP configuration, and macOS web/secure web proxy settings on active network services with localhost bypasses. Host proxy settings can affect other applications that use them.

Disable routing in the app before stopping the engine. If a proxy setting remains afterward, restore it through the app’s cleanup flow or your system’s network settings. On Windows the old guide also documents netsh winhttp reset proxy for manual recovery; only use it if you intend to clear that host setting.

Windows Rose distribution

The documented Windows app imports a managed WSL2 distribution named 404. Its Alpine root filesystem includes STATIC, ttl_editor.o, a launcher, and version metadata. The app obtains a signed release manifest, verifies the archive, writes configuration and a control token, and starts the runtime. The WSL2 kernel comes from Windows, not the Rose archive. Rose distribution anatomy and Provisioning explain the runtime and release files.

Use the app’s stop/reset flow before removing this managed installation. wsl --unregister 404 deletes that distribution’s Linux filesystem; it is not the same as the separate CLI’s 404-cli distro. The old desktop guide describes this as a manual full-removal step, not a routine way to stop a session.

Local app-managed files

The app keeps configuration, profiles, downloaded assets, cache, logs, and Windows WSL state in platform application-data locations. The published guide describes a Windows wsl/ area with downloads/, distribution/, control-token, and installed-version.json. STATIC separately owns its managed CA state. A cleanup flow should handle routing and trust before remaining app files are manually removed.

For an operating-system breakdown, continue to Platform notes.