All plugins

hermes-windows-startup

Answer "what launches itself on this machine" on Windows: win_startup_table lists every autostart entry across the six Run/RunOnce registry keys (HKCU and HKLM, plus the 32-bit views) and the two Startup folders, with where each one comes from, whether it is machine- or user-scoped, and whether the person switched it off in Task Manager - Explorer's StartupApproved verdict, with the date it was last changed, a state Win32_StartupCommand has no field for; approval records uninstalled programs left behind are reported as leftovers, their unknown state bytes surfaced as-is rather than guessed into verdicts. win_startup_detail takes one entry and resolves its command the way the loader does - quoting, arguments, environment variables, and unquoted paths with spaces resolved by longest existing prefix - and says whether the binary is still on disk, plus a folder file's size and last change. Use it for what added itself since last month, for slimming a slow sign-in, and for a launcher whose program is already gone. Read-only: nothing is enabled, disabled or deleted; the Startup folders are read through Explorer's User Shell Folders values so OneDrive-redirected folders are found. The sweep is registry and directory reads only - about a millisecond for three Run values and two folders on the machine it was written on, no PowerShell, no WMI. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure - the tools report program names, launch commands, binary paths under C:\Program Files and C:\Users\<name>, and what the person chose to keep from starting, to the model; treat the output like the Startup tab of the person's own Task Manager.

Yicheng-MarkToolsv0.1.0Updated 44 minutes ago

About

Answer "what launches itself on this machine" on Windows: win_startup_table lists every autostart entry across the six Run/RunOnce registry keys (HKCU and HKLM, plus the 32-bit views) and the two Startup folders, with where each one comes from, whether it is machine- or user-scoped, and whether the person switched it off in Task Manager - Explorer's StartupApproved verdict, with the date it was last changed, a state Win32_StartupCommand has no field for; approval records uninstalled programs left behind are reported as leftovers, their unknown state bytes surfaced as-is rather than guessed into verdicts. win_startup_detail takes one entry and resolves its command the way the loader does - quoting, arguments, environment variables, and unquoted paths with spaces resolved by longest existing prefix - and says whether the binary is still on disk, plus a folder file's size and last change. Use it for what added itself since last month, for slimming a slow sign-in, and for a launcher whose program is already gone. Read-only: nothing is enabled, disabled or deleted; the Startup folders are read through Explorer's User Shell Folders values so OneDrive-redirected folders are found. The sweep is registry and directory reads only - about a millisecond for three Run values and two folders on the machine it was written on, no PowerShell, no WMI. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure - the tools report program names, launch commands, binary paths under C:\Program Files and C:\Users\<name>, and what the person chose to keep from starting, to the model; treat the output like the Startup tab of the person's own Task Manager.

hermes-windows-startup

Answer "what launches itself on this machine" on Windows, from inside Hermes.

win_startup_table({"include_disabled": False})
win_startup_table({"scope": "machine"})
win_startup_detail({"name": "CC Switch"})

The Task Manager → Startup tab question, answered without Task Manager: what runs at
sign-in, from which of the six Run/RunOnce keys or the two Startup folders, and — the
part Win32_StartupCommand has no field for — whether the person switched it off, with
the date of that decision.

What the tools report

| Field | Where it comes from |
|---|---|
| name, command | The Run value's name and data, or the folder file, verbatim |
| source | One of six registry keys (registry-hkcu-run, registry-hklm-run-32, ...) or folder-user / folder-common |
| scope | user or machine |
| enabled, changed | Explorer's StartupApproved verdict: enabled (02/03), disabled in Task Manager (06/07), with the FILETIME of the last change; an entry with no record runs — that is Windows' default |
| leftover approvals | Records for entries that are gone — uninstalled programs leave them behind; reported, not guessed from |

win_startup_detail adds the resolution of the command: quoting, arguments and
environment variables folded in, the binary the loader would find, and whether it is
still on disk — an uninstalled launcher's Run entry keeps pointing at nothing. Unquoted
commands with spaces in the path (real machines write them) are resolved the way the
loader resolves them: the longest whitespace prefix that names a real file.

Read-only, and why it goes through the registry

Nothing is enabled, disabled or deleted: the tools enumerate, and the schemas say so.

The registry and the two folders answer in about a millisecond on this machine — three
Run entries and two folders — with no PowerShell spawn and no WMI query. Win32_StartupCommand
costs both and cannot answer the switched-off question at all, because Explorer keeps
that verdict in StartupApproved blobs the CIM class never reads.

The StartupApproved record is 12 bytes: a state word whose low byte Explorer writes
(02/03 enabled, 06/07 switched off) and a FILETIME of when it was last changed.
Other bytes occur in the wild — a record an uninstalled program orphaned reads 01 here —
and are reported as unknown with the raw byte, never guessed into a verdict.

Startup folders are read through Explorer's own User Shell Folders values, so a
OneDrive-redirected Startup folder is found where the person actually has it, not where
the default says it should be. desktop.ini is folder customization, not something
anyone launches, and is skipped.

Windows only

The plugin imports nowhere but on Windows: winreg is guarded, and on a machine without
it the tools answer with a clear error instead of crashing. Windows-only is declared in
the manifest.

Testing

python -m pytest tests/ — unit tests fake the registry and the folders, live tests
check the real machine (16 tests on the machine that produced the numbers above:
11 unit + 5 live). VALIDATION.md records the evidence.

README from the reviewed commit a216242; it updates when the author re-pins.

More by Yicheng-Mark

11 plugins by Yicheng-Mark in the catalog.

Yicheng-Markhermes-dpapi-secretsResolve Hermes environment variables at startup from a single secret file encrypted with the Windows Data Protection API, instead of keeping provider keys in plaintext in .env or auth.json. Config is secrets.dpapi.map, an ENV_VAR -> store-name mapping (bare names or dpapi:// names) plus an optional file path (default <HERMES_HOME>/secrets.dpapi). The file is one DPAPI blob keyed by the current Windows user profile, so it is unreadable by another Windows account and worthless off the machine; it is written by the bundled CLI (python -m hermes_dpapi_secrets set NAME, value read from a prompt or stdin, never from argv) and only read at runtime. Mapped names that are missing or empty are skipped with a warning; a file that is not ours, a blob this user cannot decrypt, or a payload that is not a flat string map is reported as an error with nothing injected. Disclosure - this source decrypts a file for every Hermes process that enables it: resolved values become environment variables of the Hermes process and its children, exactly like .env entries, so anything that can read that environment can see them. User-scope encryption only (the machine-wide flag is never used and is not exposed), and the at-rest protection is a bar for backups, cloud sync and dotfiles, not a boundary against code already running as the same user. Stdlib-only (ctypes): no Python dependencies, no subprocesses, no network calls, no self-update. Windows only. Applying fetched values stays the orchestrator's job; the plugin never writes os.environ itself. Disclosure — decrypts a DPAPI-encrypted secret file (default <HERMES_HOME>/secrets.dpapi) at startup for every Hermes process that enables it, and the resolved values become environment variables of Hermes and its child processes like `.env` entries; the encryption is per Windows user and protects backups, cloud sync and copied files, not against other code running as the same user. Local only: no network calls, no subprocesses.CommunitytoolsYicheng-Markhermes-wincredResolve Hermes environment variables from the current user's Windows Credential Manager at startup, instead of keeping provider keys in plaintext in .env or auth.json. Config is secrets.wincred.map, an ENV_VAR -> generic-credential-target mapping (bare names or wincred:// names); each value is read with CredReadW in the current user's vault and handed to the secret-source orchestrator, which applies it with the usual precedence, provenance and conflict rules. Values may be UTF-8 or UTF-16LE (cmdkey and the Credential UI write UTF-16); anything that does not decode to text, or that contains interior NULs, is skipped with a warning instead of being injected as a mangled key. Disclosure - this source reads your Windows Credential Manager: only the generic credentials named in the map, with no enumeration of the vault. Resolved values become environment variables of the Hermes process and its children, exactly like .env entries, so anything that can read that environment can see them. The package is read-only and stdlib-only (ctypes): it never creates, updates or deletes credentials, writes no files, starts no subprocesses, makes no network calls and does not self-update. Windows only. Credential Manager is user-scoped, so this raises the at-rest bar for backups, cloud sync and dotfiles; it is not a boundary against code already running as the same user. Applying fetched values stays the orchestrator's job; the plugin never writes os.environ itself. Disclosure — when enabled, reads only the Windows Credential Manager generic credentials named in secrets.wincred.map (no vault enumeration) and injects them as environment variables of the Hermes process and its children, exactly like .env entries; read-only, stdlib ctypes, no subprocesses, no network, no file writes; user-scoped at-rest protection, not a boundary against code already running as the same user.CommunitytoolsYicheng-Markhermes-windows-devicesAnswer "which device on this Windows machine is unhappy, and what does it need" on Windows: win_device_table lists every present PnP device with its class (System, Net, HIDClass, Display), its status, its manufacturer, its stable device id, and its problem code in words - 28 is one with no driver installed, 10 one that cannot start, 43 one Windows stopped after it reported a failure, 22 one the person switched off on purpose and is not broken - filtering by name or id substring, by class, or to the devices that need attention; devices no longer plugged in are history, left out unless asked for. win_device_detail takes one device by id or name substring and adds the driver behind it from the signed-driver table - name, version, date, provider, signer, INF file, signed or not - or the absence of one, which for code 28 is the same fact said twice; a disabled device gets a note saying it is on purpose, not an alarm. Use it for the Device Manager yellow-mark question without opening Device Manager, for finding what an uninstalled program left behind, and for what changed after an update. Read-only: nothing is enabled, disabled, updated or reinstalled. Both answers come from CIM (Win32_PnPEntity and Win32_PnPSignedDriver, joined by device id), whose property names, enum values and ids do not change with the display language; the human-facing device names localize and are carried through as data, never parsed. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure — the tools report device names, manufacturers, device ids and driver versions to the model, and those reveal the machine's hardware inventory and what is plugged into it; treat the output like a Device Manager window opened on their machine.CommunitytoolsYicheng-Markhermes-windows-eventlogAnswer "why did this process die" on Windows: three read-only tools over the Windows Event Log. win_crash_events reads Application Error / Application Hang / Windows Error Reporting / .NET Runtime records for a time window, decodes the exception code (0xC0000005 -> ACCESS_VIOLATION and the other codes a debugger would name), reports the faulting module, its path and the fault offset, and groups repeated crashes by app and signature. Records are classified by provider as well as by event id, so unrelated providers that reuse ids 1000 and 1001 for informational events are not reported as crashes. win_shutdown_events reads the System log for Kernel-Power 41 unexpected restarts, bugchecks decoded to names (0x9F -> DRIVER_POWER_STATE_FAILURE, accepting the decimal form some providers emit), EventLog 6008 dirty shutdowns, 1074 operator-initiated restarts with the process and comment, and the 6005/6006/12/13 start and stop markers. win_eventlog_query is the general case: any channel, filtered by event ids, levels, an exact provider name or a payload substring, returning structured records instead of raw XML. Queries read newest-first and stop at the window start or at a 5000-record scan cap; a call returns at most 200 records and marks truncated payload text. Channel names, provider names and numeric filters are validated before anything is interpolated into the query. Disclosure - this plugin reads the local Windows event logs and hands what it finds to the model: application and faulting-module paths, exception codes and offsets, report ids, service names and provider message text, which routinely includes user and machine paths (C:\Users\<name>\...). Treat tool output like any other local diagnostic dump when sharing it. It reads only the channels the current account may read - Security and some operational logs answer with an access-denied error rather than any attempt to obtain elevation - and it never writes to a log, clears one or configures a channel. Stdlib-only (ctypes wevtapi plus xml.etree): no Python dependencies, no child processes, no network calls, no file writes, no self-update. Windows only. Disclosure — reads the local Windows event logs and hands what it finds to the model: application and faulting-module paths, exception codes and offsets, report ids, service names and provider message text, which routinely include user and machine paths (C:\Users\<name>\...); win_eventlog_query reads any channel the account running Hermes may read, so an unelevated account gets access-denied on Security and some operational logs while an elevated Hermes can return Security-log records (logon events with account names and source addresses). It never requests elevation, never writes to, clears or configures a log, and has no Python dependencies, child processes, network calls, file writes or self-update. Windows only.Communitytools