crash-guard-dsh

config.watchdogEnabled defaults to true, so on every boot a detached child watches a 2s heartbeat file. When the heartbeat is >30s stale (any long synchronous event-loop block, GC pause, or the guard's own process dying) the child runs `taskkill /F /T` on EVERY PawWork.exe pid found by tasklist - not only the monitored instance - then relaunches PawWork.exe. `/F` skips graceful shutdown, so unsaved work/session state can be lost; other concurrently running PawWork workspaces are killed too; the watchdog is detached and unref'ed so it outlives the app; if pawworkExe cannot be resolved (spawn(un

`id` and `name` come from loader entry metadata and are written verbatim into cordis.patch.yml. A value containing a newline breaks out of the YAML comment/entry and injects arbitrary extra entries (e.g. an additional loader entry) into the profile patch that DSH parses on the next boot. index.mjs sanitises the id with yamlScalar() but leaves the name inside the generated comment, so the same class of inconsistency exists in both writers. Reachability is limited because the values normally originate from the local profile config / package names, hence low severity.

When config.patchFile is not set, the plugin takes the first cordis.patch.yml found anywhere up to 8 levels above its own directory and appends auto-disable entries to it. In a nested layout (plugin vendored inside a project or a non-DSH directory that happens to contain a cordis.patch.yml) the guard can silently rewrite a configuration file that has nothing to do with the DSH profile.