What happened
OpenClaw released v2026.10.9 on October 29, 2026. The project describes it as a maintenance release focused on security dependency patches, recovery, data preservation, and reliability rather than new end-user features. Its security changes span several parts of an agent deployment: MCP schema validation, A2UI, a Discord embedded app SDK, IMAP sender handling, and Microsoft Teams authentication.
The release updates fast-uri to version 4.2.3 so malformed URI schemes and hosts are rejected during MCP schema validation. It adds early rejection of oversized Zod collections in A2UI and the Discord embedded app SDK. For IMAP, it uses nodemailer 10.1.4 so spoofed senders cannot pass the sender-token gate. Microsoft Teams now uses patched MSAL Node 7.1.1. These are dependency-level changes, but they affect inputs and identity paths an OpenClaw installation may rely on.
The release also applies tools.fs.workspaceOnly to Gateway-built tools. According to the release notes, delegate changes still require approval and media tools remain inside the workspace. This makes the workspace constraint apply to tools constructed by the Gateway, rather than leaving that scope dependent on the particular delegate configuration. OpenClaw also says live credentials are kept out of MCP CLI inspection, while Google OAuth client secrets are masked in logs.
A second cluster of fixes addresses recovery after operational failures. Git-source rollbacks preserve operator edits rather than resetting a checkout. npm rollbacks retry transient Windows denials and report the move that restores a bootable installation. The release recovers intact agent databases and stale full-text indexes after SQLite tokenizer changes, including from update snapshots; repairs publication-complete updates after a remount; migrates large transcript archives without hitting Node.js string limits; and lets agents recover after a full disk once space is available without a restart.
Other fixes cover local-media resolution for Codex steering messages, process-cleanup reporting, Gateway recovery, working-directory selection for ACP sessions, concurrent model refreshes, SSH probing, skill metadata, and provider-ignored video-generation options. The published release record says it covers 48 unique pull requests in the v2026.10.8-to-v2026.10.9 history.
What the archive adds
This is a new release on a known, rapidly moving maintenance story. v2026.10.6 addressed eMudhra remediation and install, update, and startup problems; v2026.10.7 added session-recovery and provider-reliability work; and v2026.10.8 continued the remediation and recovery line. Version 2026.10.9 adds specific dependency patches and makes the workspace-only policy apply to Gateway-built tools.
Trend signal
This supports Agent security moves to runtime boundaries. The consequential change is not a request for the model to be more cautious: OpenClaw applies a filesystem workspace constraint to Gateway-built tools, preserves approval for delegate changes, and removes live credentials from a CLI inspection path. The release does not prove the boundary is complete, but it shows security work being expressed in tool construction, scope, logs, and update recovery.
Why now
The timing is explained partly by the release sequence. OpenClaw had already shipped several October maintenance patches for certificate-compromise remediation, installation, updates, startup, and delivery reliability. This release continues that stabilization work while naming additional dependency and identity-handling fixes. It also addresses recovery paths that become visible only when installations roll back, remount, run out of disk space, or migrate stored transcripts and databases.
Why it matters
An agent runtime is not only a model and a prompt. It contains tool builders, gateways, credentials, workspace policy, message channels, update code, and persisted state. A defect in any of those layers can turn a routine maintenance event into loss of operator changes, unavailable agents, exposed secrets, or actions outside an intended working area.
For OpenClaw operators, this release makes the practical case for treating upgrades as an operational control, especially where MCP, IMAP, Teams, Discord, Gateway delegates, or local filesystem tools are enabled. The workspace-only change is particularly relevant to teams that assume a restriction configured for an agent will necessarily be inherited by every tool path it can construct. The release says that assumption is now enforced for Gateway-built tools.
Limits and uncertainty
The release notes establish that OpenClaw changed these dependencies and behaviors, but they do not provide severity ratings, exploit reports, affected deployment counts, or independent verification of the fixes. They also do not specify every configuration in which tools.fs.workspaceOnly was previously absent from Gateway-built tools, nor do they quantify the performance or compatibility effects of the recovery changes. Teams should not infer that upgrading alone secures all custom tools, skills, credentials, or external services connected to an OpenClaw deployment.
Skill to build now
Create a short upgrade-runbook test for the agent runtime your team operates. Before applying a release, back up the agent database and configuration, record local operator changes, verify that file-capable tools are constrained to the intended workspace, and confirm that logs and diagnostic commands do not reveal active credentials. After the upgrade, run one representative tool call, one approval flow, and one recovery check. This turns a maintenance patch into a repeatable verification exercise rather than an assumption about safety.
Reader takeaway
OpenClaw v2026.10.9 is not a feature release, but it changes meaningful operational boundaries: malformed validation inputs, spoofed IMAP senders, credential visibility, filesystem scope, and failed-update recovery. Teams using its Gateway and tool integrations should treat it as a targeted maintenance update and validate their own deployment boundaries after installation.
Open question
Will OpenClaw expose clearer runtime-policy inspection or testing tools so operators can verify that every Gateway-built tool inherits the intended workspace and approval constraints?