[codex] Flag stale Windows gateway task definitions

[ooiuuii]

What does this PR do?

• Adds a Windows Scheduled Task definition audit to hermes gateway status.
• Warns when an upgraded install still has a pre-fix(windows): harden gateway scheduled task #45610 task shape: legacy .cmd launcher, no restart-on-failure, disabled StartWhenAvailable, or battery settings that can prevent/start-stop the gateway.
• Keeps the existing process liveness probes unchanged; this only adds diagnostics for stale task definitions.

Why?

• Fixes [Windows] gateway status hides stale Scheduled Task definitions after task hardening #55710.
• fix(windows): harden gateway scheduled task #45610 hardened newly-created Windows tasks, but existing installs can keep their old task definition when the user has not successfully refreshed the Scheduled Task. In that state hermes gateway status says the task is registered even though it will not relaunch after an unexpected gateway exit.

Review follow-up

• Rebased onto current main.
• Changed every definition-repair hint to hermes gateway install: Windows installs already recreate/reconcile the task, so --force is unnecessary API parity.
• Added regression coverage for malformed XML, a legacy launcher, and a non-VBS launcher; every repair hint now asserts the plain install command and rejects --force.

Proof at 7aa4980eee272455331f0422163ea86be3a1d072

• bash scripts/run_tests.sh tests/hermes_cli/test_gateway_windows.py -q — 11/11 passed.
• Ruff check on both changed files — passed.
• git diff --check — passed.
• Scoped AutoReview — clean, patch correct (0.99 confidence).
• The original native-Windows reproduction confirmed that the audit detects an existing stale Scheduled Task; this review amendment only corrects the remediation command.

Notes

• This is intentionally diagnostic-only. It does not attempt to elevate, delete, or rewrite the user's Scheduled Task from status.

[teknium1]

Thanks for adding a targeted diagnostic for persisted Windows task drift. The current status path only reports registration and runtime fields (hermes_cli/gateway_windows.py:1426), while the current task generator requires the launcher and reliability settings this PR audits (hermes_cli/gateway_windows.py:602-626).

Problems

• The new warnings tell users to run hermes gateway install --force (hermes_cli/gateway_windows.py:1317, 1326, 1331), but current Windows install() explicitly says force is only API parity and every install reconciles the task (hermes_cli/gateway_windows.py:1031). The extra flag is unnecessary.

Suggested changes

• Use hermes gateway install in each warning and assert that remediation text in the warning tests.

Automated hermes-sweeper review.

[teknium1]

install() already reconciles the Windows task on every invocation; force is accepted only for API parity (hermes_cli/gateway_windows.py:1031). Please recommend hermes gateway install here and in the other new warnings.

[randydevlab]

I reproduced this Windows gateway-status issue on a native Windows installation while troubleshooting a live Hermes gateway.

While validating #55711, I found an additional observability gap in hermes gateway status --deep:

• it reports Task script: ...\Hermes_Gateway.cmd even when the installed Scheduled Task actually executes wscript.exe ...\Hermes_Gateway.vbs
• it reports an expected Startup-folder entry even when no Startup fallback is installed

On the tested system, the actual Scheduled Task action is:

wscript.exe //B //Nologo "%LOCALAPPDATA%\hermes\gateway-service\Hermes_Gateway.vbs"

and the Startup fallback is not installed.

I built a tested follow-up on top of #55711 that:

• reports the observed Task Scheduler Exec action rather than an inferred path
• reports the actual Startup fallback state
• queries/parses the Scheduled Task XML once per status() call and reuses that observation for validation and display
• remains completely read-only

I also incorporated the July 15 review feedback locally: remediation now recommends hermes gateway install, not hermes gateway install --force.

Validation on native Windows against current upstream:

• Ruff: PASS
• Windows gateway tests: 14/14 PASS
• Python compile: PASS
• git diff --check: PASS
• live read-only hermes gateway status --deep canary: PASS
• regression coverage verifies one Scheduled Task XML query during status(deep=True)

The corrected live output is:

Task name:          Hermes_Gateway
Task action:        wscript.exe //B //Nologo "%LOCALAPPDATA%\hermes\gateway-service\Hermes_Gateway.vbs"
Startup fallback:   not installed

I kept the production Hermes checkout untouched throughout testing.

If this fits the intended scope of #55711, I'm happy to provide the tested follow-up commit or open a focused PR in whatever form is most useful.

[ooiuuii]

Thanks — you’re right. Windows install() already recreates and reconciles the Scheduled Task on every run, so --force was misleading here.

I rebased onto current main, changed all three repair hints to plain hermes gateway install, and added a regression that covers malformed XML, a legacy launcher, and a non-VBS launcher while asserting that none of the remediation text includes --force. The focused wrapper suite is 11/11, Ruff and git diff --check pass, and the scoped AutoReview is clean. Could you take another look when you have a moment?

[ooiuuii]

@randydevlab Thanks for doing the native-Windows pass — reporting the observed Task action instead of an inferred path is a useful separate improvement.

I kept this update narrow to the existing review request so the PR doesn’t grow another behavior surface this late. Your read-only/query-once approach sounds like a good focused follow-up; please feel free to open it against current main (or share the tested commit) and link #55710/#55711 so the proof and attribution stay with your work.

[randydevlab]

Thanks — I finished the focused follow-up and pushed the tested commit here:

randydevlab@eb17c25

It builds directly on the current #55711 head and keeps the change scoped to Windows gateway status observability:

• reports the observed Task Scheduler Exec command, arguments, and working directory rather than an inferred launcher path
• reports the actual current/legacy Startup fallback state
• reuses one Scheduled Task XML observation for validation and display
• fails closed on ambiguous/malformed task actions
• keeps status --deep read-only and preserves the quick status summary before the XML query

Final validation on native Windows:

• focused Windows gateway suite: 26/26 pass
• related gateway suite: 189 pass, with the same 12 Windows-host failures as untouched [codex] Flag stale Windows gateway task definitions #55711 (0 new failures)
• native read-only canary against the real Scheduled Task: pass
• normal gateway restart: pass
• full Windows reboot/persistence check: pass
• several-hour post-reboot soak: pass
• A/B timing vs untouched [codex] Flag stale Windows gateway task definitions #55711: no meaningful regression

I haven’t opened a PR yet since this commit is directly stacked on #55711. Happy to transplant it onto main once #55711 lands, or adjust the submission shape if you prefer.