Six OpenClaw Main-Branch Fixes for File Safety, Session Memory and Gateway Recovery

Six merged changes on OpenClaw main close failures at three boundaries operators should care about: an agent must not overwrite an existing file while claiming it created one, automatic session rotation must not bypass memory finalisation, and a supervised Gateway must recover predictably from startup faults.

A sixth change rejects cron webhook URLs containing embedded username/password credentials. That is safer, but it can turn an insecure configuration that previously loaded into an explicit validation failure after upgrade.

These fixes are merged source changes, not proof of inclusion in an official package. Match your deployment to a containing release or exact source revision before treating any issue as resolved.

Triage first

If none of these conditions applies, there is no case here for an emergency move to an unversioned main build. Add the relevant regression checks to the next controlled upgrade instead.

apply_patch could report success after destroying an existing file

PR #114911 fixes the sharpest issue in this group. An *** Add File: hunk wrote its target unconditionally. If that path already existed, OpenClaw replaced the file, returned success and described the path as added. A non-self *** Move to: destination had the same collision gap.

The correction gives creation exclusive semantics: if the destination exists, the operation fails with a useful error rather than converting “create” into “replace.” An intentional delete-then-add replacement remains a separate, explicit operation.

Interpretation: tool result identity is part of the safety boundary. A successful “added” result tells both the model and the reviewer that no previous content was displaced. If the implementation silently overwrites, later diff review is already working from a false premise.

Operators running older builds should not rely on prompt instructions alone. Keep agent work in version-controlled or snapshotted directories, review the resulting diff before execution continues, and investigate any path reported as newly added when history shows it already existed. Do not restore one file in isolation until you have checked whether the same turn performed other writes.

Automatic rollover archived a transcript without finalising memory

The bundled session-memory hook already persisted conversations at explicit /new and /reset boundaries. PR #61675 addresses automatic daily and idle rollovers, which bypassed that command boundary and therefore skipped the hook.

The merged path emits an internal automatic-reset lifecycle event after the ended transcript is archived and reuses the existing memory handler. The upstream record reports test and live proof for daily and idle rollover behaviour.

This is not the same as the older transcript-archive fix. A JSONL transcript can be safely retained while the memory pipeline still misses the conversation. Operators should verify both artifacts independently:

1. the old transcript is archived and attributable to the rollover;
2. the expected memory record is produced once;
3. the new session begins with a distinct identity; and
4. restart does not duplicate the finalised memory.

Use synthetic content for this test. Do not put secrets into a conversation merely to make its memory easy to identify.

Three different startup symptoms, three different causes

systemd refuses a natural recovery command

After repeated crashes, systemd can place a unit in start-limit-hit and reject another start until systemctl reset-failed clears the latch. OpenClaw’s restart path already performed that reset; its start path did not. PR #116178 makes both actions clear the failed latch before starting while leaving stop unchanged.

That makes openclaw gateway start capable of recovery, but it must not become a crash-loop eraser. Preserve the original exit status and logs, identify why the limit tripped, correct the cause, and only then start the service. A successful reset says nothing about state integrity or channel delivery.

Slack replay could block its own ingress lane

PR #115991 covers a startup ordering fault. A durable Slack event could replay before the global runtime-config snapshot was published, repeatedly fail model selection and prevent newer Slack traffic in the same ingress lane from progressing.

The fix binds channel turns and durable replay to the Gateway’s committed model-runtime owner. On an affected build, a connected Slack socket is not sufficient evidence of recovery. Compare provider event IDs with durable-ingress rows and transcript outcomes, and avoid blind bulk replay where the original side effects are uncertain.

large model rosters could starve startup publication

PR #116039 addresses prepared model runtime publication timed out on Gateways with several configured agents and model references. Upstream attributes the failure to repeated synchronous catalog preparation and garbage-collection pressure starving the event loop. The fix reuses one bundled static-catalog resolver for the prepared runtime lifecycle rather than increasing the 120-second timeout.

That distinction matters: a larger timeout would hide scaling work rather than remove it. Acceptance tests should cold-start with the production-sized agent and model roster, record time to readiness and confirm the expected models and fallbacks are actually published.

Cron webhook credentials now fail closed

OpenClaw now rejects outbound cron webhook URLs containing URL userinfo. The official cron documentation says webhook URLs must not embed username/password credentials and points operators to webhookToken for bearer authentication when supported by the receiver.

Before upgrading, inventory webhook destinations without copying full URLs into tickets or chat. If URL credentials are present:

1. rotate the exposed credential because URLs commonly leak through logs and diagnostics;
2. remove userinfo from the destination;
3. configure the supported bearer-token path or another receiver-side authentication boundary;
4. validate the job against a non-production endpoint; and
5. confirm failed delivery remains observable rather than falling back to unauthenticated delivery.

Do not “fix” validation by moving the same secret into a query string. That preserves the leakage problem.

Safe acceptance run

Use a disposable Gateway and harmless fixtures:

1. Apply an Add File patch to an existing fixture and confirm it fails without changing bytes.
2. Exercise a deliberate delete-then-add replacement and confirm the explicit path still works.
3. Trigger daily and idle rollover boundaries and reconcile transcript plus memory artifacts exactly once.
4. On Linux staging, trip a harmless systemd start limit, preserve diagnostics, correct the test failure and confirm gateway start recovers.
5. Restart with a queued synthetic Slack event and verify it plus a newer event each reach one terminal outcome.
6. Cold-start with a production-scale model roster and verify readiness, model selection and fallback state.
7. Confirm a credential-bearing cron URL is rejected and the approved token-based replacement delivers once.

Never use production commands, live customer messages or destructive file operations as test payloads.

Evidence and limits

OpenClaw Academy reviewed the official merged PR, commit and documentation-change records supplied by the repository collector. GitHub search independently surfaced the apply-patch collision semantics, automatic-rollover lifecycle, systemd validation, Slack replay mechanism and model-catalog cause. Official documentation search corroborated the cron URL rule and bearer-token alternative. Direct page extraction was unavailable in this run.

We did not reproduce these faults against a live Gateway, Slack workspace or production filesystem. Upstream test and live-proof claims remain attributed to upstream. The supplied evidence does not establish a packaged release containing all six fixes.

Bottom line

The common failure here is false success: a patch said “added” after replacing data, a rollover archived a transcript without finalising memory, and Gateways could look supervised or connected while startup work remained blocked. Adopt the relevant fixes through a confirmed containing build, then test the exact boundary you depend on rather than treating process uptime as proof of correctness.