hermes-windows-updates

Answer "what did Windows install lately, and did it work" on Windows: the update history the Settings app shows - Windows updates, Defender signature and platform updates, driver updates - newest first, with each entry's outcome in words (in progress, succeeded, succeeded with errors, failed, aborted) and, when an entry did not end clean, the failure's error code in 0x form (the agent hands codes over signed; -2145124300 is shown as its unsigned spelling). Filter to the ones that did not end clean, or search titles. The hotfix list (KB numbers, security updates, install dates, newest first) answers "when was this machine last patched" at a glance; it carries OS-level updates only, which the notes say. Use it for "why does it say pending forever", for "did the update that broke something actually install", and for a patch report before assuming a machine is current. Read-only: the history is queried through the Windows Update Agent's session interface and CIM, and nothing else - no update search is run, nothing is downloaded, installed or uninstalled, no elevation. On the writing machine a 723-entry history returns the newest 500 in about a tenth of a second; the first call also starts the COM session, about a quarter of a second. The plugin declares no Python dependencies; there is no network call of its own and no file write. Windows only. Disclosure — each tool call runs one hidden powershell.exe with a fixed read-only script (Windows Update Agent history through COM, Win32_QuickFixEngineering through CIM; no update search, download or install); the tools report update titles, dates, outcomes, failure codes and support links, and hotfix ids, descriptions, install dates and the account that installed them, to the model; treat the output like the Settings app's own update history page.

Yicheng-MarkToolsv0.1.0Updated 1 hour ago

About

hermes-windows-updates

Answer "what did Windows install lately, did it work, and when was this machine last
patched" on Windows, from inside Hermes.

win_update_history({"only_failures": True})
win_update_history({"query": "Defender", "count": 200})
win_hotfix_table({})

The update history the Settings app shows is a long list of titles with no verdicts; when
something is stuck on an old build, the answer is in there — a driver that failed three
hundred times, a feature update aborted at every attempt — but nothing in the list says so.
These two tools read the history and put the verdict in words.

What the tools report

| Field | Where it comes from |
|---|---|
| date, title, categories | The update history entry, newest first (the Windows Update Agent's session interface) |
| result | The outcome in words: 1 still in progress, 2 succeeded, 3 succeeded with errors, 4 failed, 5 aborted |
| hresult | The failure's error code, masked to its unsigned 0x spelling — the Agent hands codes over signed, so -2145124300 shows as 0x80240034, text a person can paste into a search box |
| support_url | The vendor's page for the update, when the entry carries one |

win_hotfix_table answers the other question — "when was the OS itself last patched" —
with the quick-fix list: KB ids, security updates, install dates and installers, newest
first. It carries OS-level updates only, and its notes say so; the full picture of what
Windows installed, Defender signatures and drivers included, is win_update_history's.

Read-only, and why it goes through PowerShell

Nothing is searched for, downloaded, installed or uninstalled: the tools query, and the
schemas say so. The history query deliberately touches only QueryHistory and
GetTotalHistoryCount — the same session object's Search() method is the one that goes
to the network, and it appears nowhere in this plugin.

One child process (powershell.exe, hidden window, 90 s timeout) per tool call; everything
else is plain Python. Dates are formatted inside PowerShell ('o' and 'yyyy-MM-dd')
because ConvertTo-Json serializes a DateTime as an epoch wrapper — or, through the CIM
wrapper, a nested object whose readable half follows the display language — neither of
which survives transport unchanged. Verified on Windows 11 (build 26300), unelevated:
723 history entries total, 500 of them fetched in 0.04 s, the quick-fix list in one CIM
call.

No network, no file writes, no elevation: everything these tools read is visible to a
normal user.

Layout

plugin.yaml                        manifest: tools, tags, the read-only disclosure
hermes_windows_updates/
  tools.py                         the two tools: filtering, rows, notes
  wuquery.py                       the history and hotfix queries (PowerShell)
  resultcodes.py                   result-code and hresult words
  schemas.py                       the tools' parameter schemas
tests/test_unit.py                 every layer with fakes; no PowerShell, no COM, no CIM
tests/test_live.py                 the real Agent and CIM on this machine

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

More by Yicheng-Mark

14 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.Communitytools Yicheng-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.Communitytools Yicheng-Markhermes-windows-appsAnswer "what is installed on this Windows machine": the software inventory behind Apps & Features, swept straight from the four Uninstall registry keys (the machine's 64-bit and 32-bit views plus the user's), so a program is found even when the Settings page hides it - a per-user install that never shows on the machine page came from the user view on the writing machine. Each row carries version, publisher, size in MB, install date and which view it lives in; the same DisplayName in two views is a 32/64-bit dual install, marked instead of listed twice. Entries the publisher asked to hide (runtime packages, update rollups) are filtered out unless asked for. Details one program with every field its publisher wrote and a reading of the uninstall command (MSI product code, setup executable, appx, script) so the next step is known before anything is run; the install folder is checked against disk. Use it for "what did that installer actually register", for inventory before a cleanup, and for "which of the two installs does uninstalling remove". Read-only: registry keys are enumerated and uninstall strings are reported, never run; no network, no file writes, no elevation. The sweep is pure registry - 102 entries in seven milliseconds on the writing machine, the whole table in ten, no PowerShell, no WMI. The plugin declares no Python dependencies. Windows only. Disclosure - the tools report program names, versions, publishers, sizes, install folders and uninstall commands, and what is hidden from Apps & Features, to the model; treat the output like the machine's own Apps & Features page.Communitytools Yicheng-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.Communitytools

All 14 by Yicheng-Mark