跳到主要内容

hermes-windows-tasks

❖ Communityv0.1.0★ 0

Tools · by Yicheng-Mark · added

Answer "what does this machine run on its own, and did it work" on Windows: win_scheduled_tasks lists the Task Scheduler's tasks with their state (Ready, Running, Disabled), the account each runs as, its first action's command line, its triggers in words (at logon, daily, weekly, at a time, on event), its last and next run with the machine's offset, its missed runs, and what its last result code means - 0x80070002 is a program that is no longer there, 0x800710E0 a task that needed a desktop it did not have, 0x40010004 one that was stopped, 0x80040154 a COM class that is not registered. win_scheduled_task_detail takes one task and gives its triggers with start boundaries and repetition, its actions with arguments and working directory, its principal and the settings that decide whether it runs on battery or when late; a task with no triggers but MaintenanceSettings runs during automatic maintenance and the notes say so rather than leaving an empty list. Use it for why a logon task keeps failing, for finding what an uninstalled program left behind at logon, for telling a disabled task from a broken one, and for reading a task's command line before trusting it. Read-only: nothing is created, started, changed or deleted. Reads through the ScheduledTasks cmdlets rather than the store on disk, because the TaskCache registry tree and C:\Windows\System32\Tasks both answer access denied without elevation, and rather than schtasks /Query /FO CSV, which is localized and interleaves error lines for tasks whose definitions are gone. The plugin declares no Python dependencies; there is no network call and no file write. Windows only.

Open in Hermes Desktop
hermes plugins install hermes-windows-tasks
Repository ↗Reviewed source @ 9778252 ↗Documentation ↗

What it adds

Tools 2

win_scheduled_taskswin_scheduled_task_detail

README

From the reviewed commit 9778252 ↗; it updates when the author re-pins.

hermes-windows-tasks

Answer "what does this machine run on its own, and did it work" on Windows, from inside Hermes.

win_scheduled_tasks({"query": "wps"})
win_scheduled_tasks({"failed_only": True, "include_microsoft": True})
win_scheduled_tasks({"state": "disabled"})
win_scheduled_task_detail({"name": "\\Microsoft\\Windows\\Defrag\\ScheduledDefrag"})

Windows starts a great deal of what it does, and what installed software wants it to do, through Task Scheduler: at logon, at boot, every hour, or during automatic maintenance. When one of those starts failing, the only place that says so is the "Last Run Result" column of Task Scheduler, as a number. These two tools read that column and translate it.

What the tools report

Field Where it comes from
state Ready, Running, Disabled, Queued
run_as, run_level The task's principal (a user, a SID such as S-1-5-18, or a group)
action The first action's command line
triggers The trigger classes in words: at logon, daily, weekly, at a time, on event
last_run, next_run ISO 8601 timestamps with the machine's offset
last_result The code, in hex, with what it means: 0x80070002 is a program that is no longer there, 0x800710E0 a task that needs a desktop it did not have, 0x40010004 one that was stopped
missed_runs Runs the scheduler skipped, typically because the machine was off

win_scheduled_task_detail adds what a listing has no room for: every trigger with its start boundary, repetition and schedule, every action with arguments and working directory, the principal, and the settings that decide whether a task runs on battery or when late. A task with no triggers and MaintenanceSettings runs during automatic maintenance, and the notes say so instead of leaving an empty list to be misread.

Read-only, and why it goes through PowerShell

Nothing is created, started, changed or deleted: the tools query, and the schemas say so.

The task store on disk is not readable without administrator rights. On Windows 11 (build 26300) both HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree and %SystemRoot%\System32\Tasks answer [WinError 5] Access is denied to a normal user, so a tool that walked them would work only for an elevated agent. The ScheduledTasks cmdlets run unelevated, and ConvertTo-Json gives field names and values that do not change with the display language.

schtasks /Query /FO CSV is the usual alternative and it is the wrong one: its header and state words are localized, and for a registration whose definition file is gone it prints an ERROR: Task cannot be loaded line in the middle of the rows, which is what makes naive readers of it fail (hermes-agent issue #142140 is exactly that failure in hermes gateway ensure). These tools ask the cmdlets instead.

Cost

One PowerShell call for the listing (about 1.4 s for 195 tasks on this machine) and a second one only when a single definition is asked for. There is no cache: scheduled tasks change when software is installed, and a stale answer here is worse than a slow one.

Platform

Windows only. There are no Python dependencies, no network calls and no file writes.

Disclosure

More by Yicheng-Mark

All 9 plugins by Yicheng-Mark →
hermes-dpapi-secrets❖ Community★ 0

Resolve 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.

Tools
hermes-wincred❖ Community★ 0

Resolve 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.

Tools
hermes-windows-eventlog❖ Community★ 0

Answer "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.

Tools
hermes-windows-ops❖ Community★ 0

Windows and WSL triage skills for Hermes: processes that survive a quit (orphaned stdio MCP trees, lingering python/uv/node children), WSL-to-Windows interop where an argument reaches cmd.exe as shell syntax, config and encoding traps (UTF-8 BOM, legacy console code pages), and long-path or reserved-name errors. One skill plus a copy-paste command reference; the process, argv and job-object failure modes are pinned to reports #131561, #132069 and #61059 and re-verified against current main.

Tools
hermes-windows-ports❖ Community★ 0

Answer "who holds this port" on Windows. win_port_owners reads the TCP and UDP owner tables through iphlpapi (the same rows netstat -ano prints, with the owning PID attached) and resolves each PID to its image name and path, returning one structured record per endpoint. Filters cover one port, several ports, a process substring, the protocol (tcp, udp or both), the TCP state (listen, established, any state name, or all; UDP rows report bound) and IPv6 inclusion, with a record cap and a per-process summary of the rows returned. Built for the failure mode that stalls agents on Windows: a gateway, backend or bridge that cannot bind, where the error names a port but not the process holding it. netstat -ano prints columns, not fields, and its PID still needs a second command (tasklist, or a PowerShell round-trip) to become an image name; this tool is one in-process call instead of a shell parse plus a join, with no child process and no dependency on PowerShell being installed or allowed by execution policy. A protected process whose image cannot be queried keeps its PID and reports a null process name instead of failing the call.

Tools
hermes-windows-process❖ Community★ 0

Answer "what is still running, and who started it" on Windows: win_process_table reads the process table (PID, parent PID, image name) and adds each process's image path and creation time, then marks every row with whether its recorded parent is still the process that spawned it. Windows stores a parent PID rather than a handle, so a child that outlived its parent points at a PID that is either unused or reused by a newer process; a parent that started after its child cannot have spawned it, so both cases are reported as gone or reused instead of a plausible but wrong parent name. Filters cover one PID, several PIDs, a name or path substring, a parent PID, and an orphans-only view of what outlived its parent, with a result cap and an option to leave out Windows session processes. Use it for leftover gateway/backend/server children after a quit, for telling thirty python.exe rows apart by start time, and for checking whether a process started before or after the thing being debugged. Read-only: processes are opened with PROCESS_QUERY_LIMITED_INFORMATION for QueryFullProcessImageName and GetProcessTimes only - no memory reads (command lines are deliberately out of scope), no handle duplication, no writes, no child processes. Stdlib-only (ctypes): no Python dependencies, no network calls, no file writes, no self-update. Windows only.

Tools

← Back to the catalog · catalog built Oct 29, 2026