代理框架與安全
OpenClaw 2026.9.2 Enables Cross-Agent Session Access by Default, Potentially Expanding Conversation Visibility After Upgrades
The new release gives eligible agents Swarm collaboration capabilities by default and can resume some interrupted tasks after a restart. More importantly, two previously unspecified settings now permit cross-agent reading and communication, requiring operators of shared Gateway deployments to review their permissions.
OpenClaw 2026.9.2 moves multi-agent functionality from an experimental feature flag to a default capability: eligible agents can now use Swarm to dispatch parallel subtasks and aggregate text or structured results, although the feature can still be disabled in settings. Large fan-outs are queued when all concurrency slots are occupied, and some interrupted sub-agent tasks can resume through a constrained queue after the Gateway restarts.
The area that truly requires review during an upgrade is session permissions. If an existing configuration does not explicitly set `tools.sessions.visibility`, its default changes from `agent` to `all`; if `tools.agentToAgent.enabled` is unspecified, its default changes from `false` to `true`. As a result, agents with the relevant tools can list, read, search, or send messages to other agents’ sessions, potentially including transcripts belonging to other users. This is intended to enable direct collaboration among agents on the same Gateway and is not a vulnerability, but it is a behavioral change for multi-tenant or tiered-permission deployments. Administrators should explicitly set visibility to `self` or `agent`, configure an allowlist of permitted agent pairings, and run `openclaw security audit`. Mutually untrusted users should continue to use separate Gateways, credentials, and operating system accounts.
On the model side, the release adds GPT-6 Astra and Muse Spark 1.3. When using the official OpenAI Responses API, an API key, and the built-in runtime, Astra can continue responding while direct tools run in the background and can receive midstream corrections over a cached WebSocket connection. The SSE and native Codex paths do not provide full feature parity. The new release can also preserve other connections and in-progress calls when one MCP server is modified.
Recovery does not provide exactly-once semantics: if a final response has already been displayed but its completion state has not yet been persisted, the response may still be duplicated after a crash, and external side effects are not guaranteed to occur only once. Engineering teams should therefore add idempotency keys to tools for payments, deployments, message delivery, and similar operations, and include the two new permission defaults in their upgrade tests.