🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 Locale-dependent Scheduled Task status misclassified as STOPPED, causing unsafe process termination during restart health checks

Description

The Windows scheduled-task runtime derivation now defaults to stopped whenever the task status string is non-empty but not recognized as a running status.

• isRunningTaskStatus() only recognizes:
  • English "Running"
  • German "Wird ausgeführt" (via startsWith("wird ausgef") after normalization)
• For other locales where the schtasks key is still Status but the value is localized (e.g., Dutch, etc.), a running task may be reported as stopped when Last Run Result is missing/unparseable.
• Downstream, restart health checks on Windows treat runtime.status !== "running" as a signal that any OpenClaw listener PIDs are stale and should be killed. This can terminate a legitimately running gateway process, creating an availability/DoS risk during update/restart flows.

Vulnerable logic:

if (!isRunningTaskStatus(parsed.status)) {
  return { status: "stopped" };
}

Data-flow / impact chain:

• Source: schtasks /Query /V /FO LIST output → parsed into ScheduledTaskInfo.status
• Decision: deriveScheduledTaskRuntimeStatus() classifies runtime as stopped
• Sink: restart-health logic may include gateway listener PIDs as stale when status !== "running", and callers (restart/update flows) can terminate those PIDs.

Recommendation

Treat unrecognized localized Status values as unknown unless a reliable numeric Last Run Result indicates running/stopped.

Suggested change (safer default):

const normalizedResult = normalizeTaskResultCode(parsed.lastRunResult);
if (normalizedResult && RUNNING_RESULT_CODES.has(normalizedResult)) {
  return { status: "running" };
}

​// If the status is not confidently recognized, don't assume stopped.
if (!isRunningTaskStatus(parsed.status)) {
  return {
    status: "unknown",
    detail: "Unrecognized Scheduled Task status string; locale-dependent and no numeric Last Run Result available.",
  };
}

​// Status looks like running; only treat as stopped if we have a non-running numeric result.
if (normalizedResult) {
  return {
    status: "stopped",
    detail: `Task Last Run Result=${parsed.lastRunResult}; treating as not running.`,
  };
}

return { status: "running" };

Additionally:

• Consider expanding isRunningTaskStatus() to recognize more locales only as a best-effort enhancement, but keep the default as unknown to avoid unsafe remediation.
• Alternatively, change restart-health logic on Windows to confirm reachability/port ownership even when runtime status is unknown/not-running, rather than immediately treating listener PIDs as stale.

Analyzed PR: #41034 at commit adb53b4

_{Last updated on: 2026-03-09T13:33:32Z}

Greptile Summary

This PR fixes openclaw node status incorrectly reporting stopped for tasks running on localized (non-English) Windows hosts by adding Unicode-aware status normalization and explicit recognition of the German running state "Wird ausgeführt" (including its mojibake form). The tui-event-handlers changes are cosmetic import reordering only.

Key changes:

• normalizeTaskStatus applies NFKD decomposition and diacritic stripping so that accented characters collapse to their ASCII base forms before comparison.
• isRunningTaskStatus recognises both "running" (English) and the "wird ausgef…" prefix (German/mojibake).
• deriveScheduledTaskRuntimeStatus is restructured: the result code is checked first (authoritative), then the status text is consulted.

Issues found:

• The test description on line 113 of schtasks.test.ts still reads "treats localized status without result code as unknown" but the expectation was updated to { status: "running" } — a stale name that actively misleads future readers.
• Any non-English, non-German running status text (e.g. French "En cours d'exécution") that arrives without a 0x41301 result code will now return { status: "stopped" } instead of the previous { status: "unknown" }. This is a regression for those locales in edge cases where the result code has not been populated yet (e.g. very early in task startup).

Confidence Score: 3/5

• Safe to merge for English and German locales; introduces a regression for other localized running states that lack a result code.
• The core German fix is correct and well-tested. However, the new control flow silently classifies any unrecognized localized running status as stopped (was unknown), which is a more harmful false-negative for other locales. The stale test description is a minor quality issue.
• src/daemon/schtasks.ts — review the isRunningTaskStatus / deriveScheduledTaskRuntimeStatus interaction for non-German localized running states without a result code.

_{Last reviewed commit: adb53b4}