Windows Agents Keep Freezing: What We Learned from an OpenClaw Merge and a Hermes Maintainer Reply

Windows is a hard place to run long-lived AI coding agents.

The failure mode is often not dramatic. A terminal window may still be open. A process may still exist. The agent may even look alive for a while. But halfway through a task, the gateway stops responding, memory search breaks, or a background service quietly disappears.

Over the past few weeks, we have been turning those local Windows failures into evidence, pull requests, and maintainer conversations.

This post summarizes two concrete trails:

• OpenClaw merged our fix for a transient Windows file-lock problem in memory index swaps.
• Hermes did not merge our Windows gateway helper PR, but a maintainer explained how this work fits into a broader Windows support plan.

That distinction matters. One was merged. The other became useful input for a larger design. Both are part of making Windows agent work more reliable.

OpenClaw: A Small Windows File-Lock Fix That Actually Merged

OpenClaw PR #76024:

https://github.com/openclaw/openclaw/pull/76024

The issue was narrow but real. During memory reindexing, OpenClaw swaps SQLite index files. On Windows, a short-lived file handle from the system, an indexer, antivirus software, or another process can make fs.rename fail with errors such as:

EBUSY
EPERM
EACCES

From the user side, this can look like memory search failing or an agent task getting stuck. The root cause is less exciting: a transient Windows file lock hits the index swap at the wrong moment.

The fix was intentionally small. It adds bounded retries around the atomic index swap path. It does not rewrite the memory system, change SQLite behavior broadly, or pretend every failure is recoverable.

That kind of fix is not flashy, but it matters. Stability work often looks like this: a small guard around a real edge case that users keep hitting.

Follow-Up Work: Cleaning Up Failure Paths

Another OpenClaw trail is PR #59137:

https://github.com/openclaw/openclaw/pull/59137

This was not our original PR. We joined with a focused follow-up around cleanup ordering in a failure path.

The main work preserved retry state and embedding cache across reindex rollback. The remaining problem was more mundane: make sure the temporary database is closed before temporary SQLite files are removed.

On Windows, this detail matters. If a temp database handle is still open, deleting related files may fail even if the higher-level logic looks correct.

This is a useful lesson for agent tooling: the happy path is not enough. The rollback path and cleanup path often decide whether the tool feels reliable.

Hermes: Not Merged, But Not Ignored

Hermes PR #15846:

https://github.com/NousResearch/hermes-agent/pull/15846

Our proposal focused on Windows gateway lifecycle management:

• start the gateway through a user-level Scheduled Task;
• avoid relying on a visible PowerShell or CMD window;
• check runtime state instead of trusting a window;
• keep logs;
• provide best-effort restart behavior.

The PR was closed and not merged. That needs to be stated clearly.

But the maintainer response was still useful. The Hermes team explained that they were closing a cluster of native-Windows PRs because Windows support needs a consolidated design, not a series of piecemeal merges. They also noted that this work was catalogued into the internal Windows support plan and may be referenced when that consolidated PR lands.

For open-source work, that is a real outcome. Not every useful contribution ends as a direct merge. Sometimes the value is in clarifying a failure mode and giving maintainers evidence they can use in a larger design.

The Practical Lesson: Do Not Trust the Window

One Windows pattern keeps showing up: a visible terminal window gives false confidence.

It can remain open while the gateway is dead. It can be accidentally closed. It can inherit a different environment from the service path. WebSocket state, process state, and user-visible window state are not the same thing.

For Windows agents, the safer pattern is:

• run quietly when possible;
• make health checks visible;
• keep logs;
• test upgrades with small tasks first;
• avoid chasing every new release before checking recent issues and PRs;
• keep rollback options ready.

Why We Are Writing This Down

AI-agent demos often focus on what the model can do. Real usage eventually runs into less glamorous problems: process lifecycle, file locks, proxy inheritance, background services, logs, and recovery.

Those problems are not side quests. They decide whether the tool can do work reliably.

Our plan is to keep collecting Windows agent stability cases and turn them into public evidence:

• reproducible failures;
• focused pull requests;
• maintainer conversations;
• screenshots and logs;
• regression notes;
• practical user-facing guidance.

If you are running coding agents on Windows and keep seeing frozen tasks, gateway failures, or memory/indexing issues, we would like to compare notes.

This trail will continue through the OpenClaw / Hermes upstream evidence path on the English blog page, with future PRs, issues, maintainer replies, and verification screenshots added as the work evolves.