OpenClaw published v2026.11.3 on November 10, 2026. The release notes state “No new configuration options or features,” and the audited record lists 34 pull requests since v2026.11.2. Most of them fall into two groups: where credentials are allowed to travel inside a running Gateway, and what an operator sees when a tool call fails. About two hours later the project also published v2026.9.37 on its extended-stable line. For a solo operator or small business running one Gateway with several plugins and API keys, both releases change day-to-day behavior without requiring any configuration work.
Credentials stay with the connection that owns them
The largest group of fixes in v2026.11.3 concerns credential scope. Under the heading “Credential isolation,” the release notes say the Gateway now keeps “reused and cached plugin results scoped to their connection credentials,” and keeps other plugins’ transport hooks on the provider’s origin. A second entry states that Firecrawl search and scrape keys stay with their scoped endpoints, and that embedding credentials stay with their destination.
Two related fixes cover places where a key could appear in output. The notes list redaction of “inline environment credentials from configuration reads” and of search credentials reflected in Exa error messages. Another fix prevents managed Signal daemons and bundled language servers from inheriting unrelated Gateway secrets through their process environment.
These changes apply within the model described in OpenClaw’s secrets management documentation. That documentation explains that supported credentials can be stored as SecretRefs so they do not need to live as plaintext in configuration, and it carries a warning that operators should read closely: plaintext credentials “remain agent-readable when they sit in files the agent can inspect,” including openclaw.json and .env. The runtime model page adds that SecretRefs “are not a process-isolation boundary,” and that tool results and transcripts do not mask a plaintext key the agent reads from disk.
The practical reading for a small operation is that v2026.11.3 narrows what the Gateway itself does with a credential, while the operator remains responsible for where keys are stored. The documentation names one command as the check for that second part: openclaw secrets audit --check, which reports plaintext values at rest in the configuration file, the auth-profile store, .env and generated model files.
Tool failures are reported instead of ending as a success
The second group of changes affects what an operator sees in chat. The release highlight titled “Visible tool failures” says the Gateway will “report unanswered tool failures instead of silently ending a user-addressed turn as a success.” Before this change, a turn in which a tool failed and the model did not respond to the failure could finish with no visible sign that anything went wrong.
Authentication errors changed in the same direction. The notes say stalled provider authentication now stops at the run deadline, with cancellation propagated through the authentication work. Credential-read failures are surfaced “rather than treating them as missing credentials,” and an explicitly selected auth profile that belongs to an incompatible provider is rejected. For anyone who has seen an agent report that a key is missing when the real problem was an unreadable credential store, the error should now describe the actual cause.
One fix is specific to operators whose Anthropic usage is capped. OpenClaw now recognizes an exhausted usage-limit error “without spending the transient rate-limit retry budget,” so a hard cap is no longer retried as if it were a temporary rate limit. This site’s guide to recovering a failed agent run covers the general practice of telling a retryable failure from a terminal one.
Sub-agent results and handoffs
Two highlights concern delegated work. “Private task results” keeps private subagent completions out of streamed chat replies. “Reliable child-task handoffs” lets a parent hand off to replacement work after cancelling a child, without the cancelled child’s completion receipt blocking the handoff.
OpenClaw’s sub-agent announce documentation describes the delivery path these fixes touch: a completed child’s result is handed to the requester, and duplicate delivery is suppressed through recorded completion facts. Operators who run review loops or specialist teams, covered in this site’s report on review-loop subagents, are the group most likely to notice the handoff fix.
Scheduled jobs, updates and sandboxed images
Three smaller fixes matter for unattended Gateways. The scheduler now handles queued cron storage failures “without exiting the Gateway,” and clears one-shot cleanup when a job becomes recurring. That continues the scheduler work in v2026.11.1 and v2026.11.2, covered in this site’s report on missing-job fixes, and applies to any job set up through OpenClaw cron jobs.
Update recovery also changed. When the initial package-presence check times out, the updater now requires “a fresh valid directory identity before replacement” and retains rollback to the original package. Profile-backed updates recognize their own maintenance lock instead of being blocked by it.
For sandboxed agents, the notes say required-sandbox image previews stay inside allowed folders “even in Full Access mode,” while explicit administrator image allowances are preserved. A Gateway performance entry reduces startup module-file loading overhead and removes a stall in abort-command detection on long punctuation runs.
The extended-stable release, and who it is for
v2026.9.37 is a different kind of release. Its notes describe it as “a gateway-only extended-stable release” that is “OpenClaw from the end of September 2026, plus critical security updates, reliability and performance fixes, and features like new model support.” It carries several of the same fixes as the current line, including the maintenance-lock fix for profile-backed updates, and adds others, such as keeping paired-node photos and screenshots from being attached to replies automatically.
OpenClaw’s release channels documentation lists four channels: stable, extended-stable, beta and dev. It recommends stable for most users and describes extended-stable as a trailing supported-month package channel that is package-only and “never applies automatically.” Switching is one command, openclaw update --channel extended-stable, and the documentation states that the updater stops on verification errors with no fallback to another channel.
The tradeoff is direct. Extended-stable gives a business that depends on one working setup fewer behavior changes per month, at the cost of waiting for newer features such as the Knowledge plugin scribes covered in yesterday’s report. Updates on that channel are manual, so the operator has to check for them.
What to do after updating
- Update on the current channel, following the checked and reversible process in this site’s report on update guardrails.
- Run
openclaw secrets audit --checkand move any plaintext key it reports into a SecretRef. - Rotate any key that was pasted into a chat or printed in an error message before the redaction fixes.
- Trigger one scheduled job and one delegated task by hand, and confirm that a failure now produces a visible message.
- Decide once whether the Gateway belongs on stable or extended-stable, and record the choice with the rest of the setup notes.
Readers setting review boundaries for agents that hold real credentials can use the guide to permissions and human review, and readers comparing how different agent systems handle secrets can start with the AI agent harness guide.