Summary

Windows package updates no longer hard-fail when schtasks /Change /DISABLE reports an access-denied error; the update now warns and continues, leaving the task in its prior enabled state.

• Problem: openclaw update on Windows hard-exits with Failed to stop managed gateway service before update: Error: schtasks disable failed: 错误: 拒绝访问。 whenever the current shell lacks permission to disable the OpenClaw Scheduled Task (task owned by another identity or an elevated shell required), blocking the update entirely.
• Solution: In maybeSuspendWindowsTaskAutoStartForPackageUpdate, detect access-denied failures (localized Access is denied / 拒绝访问 / Zugriff verweigert) and degrade to a warn+continue path instead of re-throwing. Other schtasks failures stay fatal.
• What changed: src/cli/update-cli/update-command-service.ts (added WINDOWS_ACCESS_DENIED_PATTERNS + isWindowsAccessDeniedError helper + access-denied branch in the catch block), src/cli/update-cli.test.ts (added 4 regression tests covering en/zh/de localizations plus a non-access failure that must still hard-fail).
• What did NOT change: schtasks /Query failure handling (still fail-closed via existing tests), changeScheduledTaskEnabledState itself, the armWindowsTaskAutoStartRecovery signal/restore plumbing, the resume path, the package-install execution path, non-Windows platforms, git-update path, service.stop() invocation, exit/abort semantics for non-access failures.

Change Type

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related to [Bug]: openclaw update failed - SQLite state has conflicting #111756
• This PR fixes a bug or regression

Motivation

Issue #111756 reports openclaw update 2026.7.1 failing on Windows 11 with schtasks disable failed: 错误: 拒绝访问。. The error is raised by changeScheduledTaskEnabledState in src/daemon/schtasks.ts:1844-1846 when schtasks /Change /TN <task> /DISABLE returns a non-zero exit code, and is re-thrown by maybeSuspendWindowsTaskAutoStartForPackageUpdate. The catch block in executeMutableUpdate then logs Failed to stop managed gateway service before update and calls defaultRuntime.exit(1), aborting the update before the package install can run.

The actual failure is a user-permission gap, not a code defect: schtasks /Change requires permission to modify the task, and an npm-installed OpenClaw whose Scheduled Task was registered by another identity (or an elevated shell) cannot be disabled from a non-elevated user shell. Hard-failing here blocks the update entirely with no recourse short of re-running as Administrator. The task remains in its prior enabled state when /Change /DISABLE fails, so suspending autostart was never going to succeed; continuing the update is safe and matches the impact:ux-friction signal on the issue.

Real behavior proof

• Behavior addressed: Windows openclaw update continues with a warning when schtasks /Change /DISABLE returns an access-denied error, instead of hard-exiting.
• Real environment tested: Linux x86_64, Node v24.15.0, branch fix/schtasks-disable-access-denied-111756, Vitest 4.1.10 with existing vi.mock-based Windows schtasks simulation in src/cli/update-cli.test.ts.
• Exact steps or command run after this patch:

node scripts/run-vitest.mjs src/cli/update-cli.test.ts -t "Scheduled Task disable" --run
node scripts/run-vitest.mjs src/cli/update-cli.test.ts --run
node scripts/run-vitest.mjs src/daemon/schtasks.stop.test.ts --run
node_modules/.bin/oxlint src/cli/update-cli/update-command-service.ts src/cli/update-cli.test.ts
node_modules/.bin/oxfmt --write src/cli/update-cli/update-command-service.ts src/cli/update-cli.test.ts
node_modules/.bin/tsgo -p tsconfig.core.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core.tsbuildinfo

• Evidence after fix:

$ node scripts/run-vitest.mjs src/cli/update-cli.test.ts -t "Scheduled Task disable" --run
 RUN  v4.1.10
 ✓ |cli| src/cli/update-cli.test.ts (196 tests | 192 skipped) 146ms

 Test Files  1 passed (1)
      Tests  4 passed | 192 skipped (196)
   Duration  8.11s

$ node scripts/run-vitest.mjs src/cli/update-cli.test.ts --run
 ✓ |cli| src/cli/update-cli.test.ts (196 tests) 49869ms

 Test Files  1 passed (1)
      Tests  196 passed (196)
   Duration  69.40s

$ node scripts/run-vitest.mjs src/daemon/schtasks.stop.test.ts --run
 ✓ |daemon| src/daemon/schtasks.stop.test.ts (20 tests) 336ms

 Test Files  1 passed (1)
      Tests  20 passed (20)
   Duration  3.00s

$ node_modules/.bin/oxlint src/cli/update-cli/update-command-service.ts src/cli/update-cli.test.ts
Found 0 warnings and 0 errors.
Finished in 55ms on 2 files with 212 rules using 8 threads.

Matrix-style evidence for the catch-block branches (input form → result):

schtasks disable failure detail              => Result
"ERROR: Access is denied." (en)             => warn + continue + return undefined
"错误: 拒绝访问。" (zh-CN)                  => warn + continue + return undefined
"Zugriff verweigert" (de)                   => warn + continue + return undefined
"schtasks timed out after 15000ms" (other)  => re-throw + defaultRuntime.exit(1)

• Observed result after fix:
  1. When schtasks /Change /DISABLE fails with an access-denied message in any of the three localized forms, the update no longer calls defaultRuntime.exit(1); the package install proceeds, resumeScheduledTaskAutoStartAfterUpdate is not invoked (since no suspend actually succeeded), and the warning log names the failure detail and the openclaw gateway restart recovery command.
  2. When schtasks /Change /DISABLE fails for any other reason (e.g. timeout, malformed output), the prior hard-fail behavior is preserved: defaultRuntime.exit(1) is invoked, no package install runs, and the error log retains the original Failed to stop managed gateway service before update message.
• What was not tested: No real Windows schtasks /Change /DISABLE run on an access-denied Scheduled Task was performed (no Windows host with the failure condition available). Behavior on locales beyond en/zh/de is not covered by the pattern list and would still hard-fail until a real report surfaces and the locale is added. The src/infra/boundary-file-read.ts tsgo errors present during local typecheck exist on origin/main baseline (confirmed via git stash + re-run) and are unrelated to this change.

Root Cause

schtasks /Change /TN <task> /DISABLE returns a non-zero exit code with locale-localized stderr (e.g. ERROR: Access is denied. / 错误: 拒绝访问。 / Zugriff verweigert) when the calling shell cannot modify the task. changeScheduledTaskEnabledState (src/daemon/schtasks.ts:1844-1846) throws schtasks disable failed: <detail>, which maybeSuspendWindowsTaskAutoStartForPackageUpdate re-throws, and executeMutableUpdate (src/cli/update-cli/update-command-execution.ts:100-108) catches by calling defaultRuntime.exit(1) and throwing UpdateCommandAbort. The user-permission gap is treated identically to a real schtasks malfunction, blocking the entire package update.

Confidence: clear. The throw site, catch site, and exit path are all directly cited in source.

Regression Test Plan

Four new it cases added to src/cli/update-cli.test.ts inside the existing update-cli describe block, exercising the maybeSuspendWindowsTaskAutoStartForPackageUpdate catch branch through the public updateCommand entry point:

1. continues a no-restart package update when Windows Scheduled Task disable reports access denied (en) — assert defaultRuntime.exit not called with 1, package install runs, resume not called, warn log contains detail + openclaw gateway restart.
2. Same for zh (错误: 拒绝访问。).
3. Same for de (Zugriff verweigert).
4. still hard-fails a no-restart package update when Windows Scheduled Task disable fails for a non-access reason — assert defaultRuntime.exit called with 1, package install never runs, resume not called, error log contains Failed to stop managed gateway service before update + the original detail.

The existing schtasks.stop.test.ts suite (20 tests) continues to cover the lower-level changeScheduledTaskEnabledState throw paths and the /Query fail-closed behavior, ensuring the access-denied branch only relaxes the /Change /DISABLE failure mode.

User-visible / Behavior Changes

• On Windows, when the OpenClaw Scheduled Task cannot be disabled before a package update due to an access-denied error, the update now proceeds with a warning (Could not disable the Windows Scheduled Task before update ... Run \openclaw gateway restart` from an elevated shell if the gateway fails to restart after update.) instead of aborting with Failed to stop managed gateway service before update: Error: schtasks disable failed: ` and exit code 1.
• All other schtasks disable failures (timeouts, malformed output, etc.) retain the prior hard-fail behavior.

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

The change only relaxes the failure handling for one specific class of schtasks error; no new schtasks invocations, no new file paths, no new env vars, no new permissions.

Repro + Verification

Environment

• OS: Windows 11 (issue reporter); Linux x86_64 for local test verification
• Runtime/container: Node v24.15.0
• Model/provider: N/A
• Integration/channel: N/A
• Relevant config (redacted): npm-installed OpenClaw 2026.06.11 → 2026.7.1 with a Scheduled Task registered under another identity

Steps

1. Install OpenClaw via npm on Windows under an elevated shell (Scheduled Task registered under admin identity).
2. Open a non-elevated user shell and run openclaw update 2026.7.1.
3. Observe schtasks disable failed: 错误: 拒绝访问。 and the subsequent Failed to stop managed gateway service before update error.

Expected

After this fix: a warning Could not disable the Windows Scheduled Task before update ... is logged and the package update proceeds.

Actual

Before this fix: openclaw update exits with code 1 before the package install runs.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification

• Verified scenarios: catch-block branching on en/zh/de access-denied (continue) and non-access failure (hard-fail); package install call site; resume call site; exit code.
• Edge cases checked: already-disabled task path (pre-existing test coverage in schtasks.stop.test.ts), task-absent path (pre-existing coverage), COM-proved absence path (pre-existing coverage), suspension-signal path (pre-existing coverage in update-cli.test.ts).
• What you did NOT verify: real Windows schtasks /Change /DISABLE on an actual access-denied task; locales beyond en/zh/de; behavior under antivirus interference that produces a non-access-denied stderr.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

No config, env, or storage surface changes. Existing schtasks failures that are not access-denied continue to hard-fail exactly as before. The new pattern list is internal to update-command-service.ts and grows only when a real report surfaces a new locale.

Best-fix Verdict

Is this change the best way to solve the problem?

• Best fix: Yes. The fix is at the caller boundary (maybeSuspendWindowsTaskAutoStartForPackageUpdate) where the Windows-specific package-update suspension is decided, not at the lower-level changeScheduledTaskEnabledState (which would change behavior for /Query paths and other callers). The pattern-based locale detection is anchored to observed real-world localizations (issue [Bug]: openclaw update failed - SQLite state has conflicting #111756 + existing test fixtures using Access is denied and Zugriff verweigert), not speculative, and the comment instructs future contributors to extend only on real reports. Returning undefined reuses the existing "no suspension happened" semantics already used by the !suspended branch, so no new recovery plumbing is needed.
• Refactor needed: No. The change is 32 lines of source + 73 lines of regression test, scoped to a single catch block.
• Alternative considered:
  • Alternative A: warn+continue for any /Change /DISABLE failure (not just access-denied). Rejected because it would mask real environmental problems (antivirus locks, schtasks binary corruption) that the existing fails closed on an ambiguous task query test philosophy explicitly guards against.
  • Alternative B: print a clearer error message but keep exit(1). Rejected because the issue's impact:ux-friction label signals the user is blocked, and a friendlier failure does not unblock the update.
  • Alternative C: probe task ownership and skip disable if the current user is not the owner. Rejected as over-engineered — Windows task ownership probing requires extra COM calls and the simpler "warn + continue" already covers the user-visible problem.

AI Assistance

• AI-assisted: Yes
• AI model: glm-5.2 (openai-compatible/glm-5.2)
• Human confirmed understanding of code changes: Yes
• AI prompts / session excerpts: User instructed "[Bug]: openclaw update failed - SQLite state has conflicting #111756 用开源skill". The open-source-pr skill was loaded, Step 1-7 workflow followed, Decision Gate 1 (issue acceptance) and Decision Gate 2 (technical plan: access-denied → warn+continue) confirmed by the user before implementation. The user explicitly chose Plan A (precise access-denied detection) over Plan B (any disable failure → continue) and Plan C (cosmetic message change).

Risks and Mitigations

• Highest-risk area: A user whose Scheduled Task remains enabled during the update could see the task auto-start the gateway mid-update if Windows fires the LogonTrigger or a manual schtasks /Run is invoked while the package install is replacing files. In practice this is low: the user is already logged in (LogonTrigger already fired) and maybeStopManagedServiceBeforeMutableUpdate separately calls service.stop() when the gateway is running, which terminates the process directly without relying on the disable bit.
• Mitigation: The warning message explicitly tells the user to run openclaw gateway restart from an elevated shell if the gateway fails to restart after the update, restoring the task to a known-good state.
• Compatibility impact: No breaking change. Existing users whose schtasks disable succeeds are unaffected. Users whose schtasks disable fails with a non-access-denied message continue to see the prior hard-fail.
• Locale coverage: Only en / zh-CN / de are detected today. A user reporting a different locale (e.g. fr, ja) will still hard-fail; the comment in WINDOWS_ACCESS_DENIED_PATTERNS instructs adding the locale only when a real report surfaces it, matching AGENTS.md's "handle real production states" guidance and avoiding speculative expansion.

Related to #111756