OpenClaw published v2026.11.5-beta.2 on November 12, 2026, the second pre-release of the 2026.11.5 line. Its first highlight is that large conversations stay browsable through paged history in both directions, with visible history boundaries and bounded archive reads. Other fixes in the same build change what happens when a chat message is sent twice and when a tool call runs out of time. Both builds are pre-releases, so the changes below apply to operators on the beta channel and reach the stable channel only after promotion.
Large conversations are read in pages
An OpenClaw assistant that serves direct messages from several channels keeps one rolling conversation, which grows without limit unless it is compacted or reset. The session management documentation says all session state is owned by the Gateway and that interface clients query the Gateway for it. The beta.2 highlight changes how long histories are read back: paging works in both directions, the point where history stops is shown, and archive reads are bounded.
The session documentation describes the storage side of the same work. Compressed transcript archives are decoded directly from their source files, and history, discovery, usage and memory indexing no longer create plaintext copies in the temporary directory. History keeps navigation metadata and reads selected byte ranges through a bounded-memory stream. An archive that would expand past 4 GiB fails with a visible error and is left unchanged. The page also notes that openclaw doctor --fix, which also runs during updates, removes read-cache directories left by older versions, and that files still open on Windows may remain until a later run.
For a small business with an assistant that has handled months of customer messages, the practical effect is that opening an old conversation reads one page at a time instead of the whole archive. The beta.2 fixes list adds that session listing, imported-history reads and accounting reads are bounded “without blocking writers,” and that centered history omits misleading continuation metadata.
A retried message no longer produces a second reply
Chat channels retry. A phone loses signal after sending, a client resends, and the Gateway receives the same input twice. The session documentation now states the rule: retries with the same input key acknowledge an already committed input even after another turn has started, and they do not append another user message or generate a second reply. Interrupted current turns can still resume, and reusing a key for conflicting content or sender identity is refused.
The beta.2 fixes list ties this to message delivery. It lists acknowledging “retried committed input without starting duplicate turns,” retaining queued messages during inline edits, and keeping Control UI plugin-reload replies from leaking into the last external chat. The last item matters to anyone who tests changes in the Control UI while the same assistant is connected to customers, because a reply meant for the operator could previously land in the most recent outside conversation.
Timed-out tools are no longer read as clean failures
Version 2026.11.3, covered in this site’s report on credential scoping and visible tool failures, made unanswered tool failures visible. Beta.2 adds a related distinction. Its fixes list says OpenClaw will “retain timeout results so interrupted tools are not mistaken for confirmed failures without side effects.”
The difference matters for tools that change something outside the assistant, such as sending a message, writing a file or creating a record. A tool that timed out may have finished the action before the timeout, and a plain failure would suggest it did not. Keeping the timeout result lets the next step treat the outcome as unknown. This site’s guide to recovering a failed agent run recommends checking the real state before repeating an action that has side effects, and this change gives the assistant the information it needs to follow the same rule.
Related entries cover delegated work. Subagent turns and model fallback now stay aligned with changed session capabilities, and child approval requests are surfaced to parents that use custom session stores. Operators running review loops or specialist teams, described in the report on review-loop subagents, are the group most likely to see these.
Secrets survive failed saves on macOS
The second beta.2 highlight is specific to the macOS app. It says the app preserves saved secrets and Gateway authentication when configuration saves fail or when Tailscale exposure is turned off. Several related macOS fixes follow: typed authentication references are resolved, configured credentials are preferred over stale app environment values, and a stale Gateway service is replaced safely after an in-place update. Android gets one fix of its own, where ending Talk no longer cancels work the Gateway has already accepted.
What else shipped in the first beta
The 2026.11.5 line began with v2026.11.5-beta.1 on November 4. Its highlights include Knowledge Scribes, a PostgreSQL-backed state option with migration tooling, a reworked Control UI, pull-request preparation and review from chat, and backup and upgrade safety work. This site covered the scribes in its report on knowledge scribes. An operator should read the full notes before treating any of these items as a default.
Who should try the beta
The release channels documentation lists four channels and recommends stable for most users. It explains that stable builds usually ship to beta first, get vetted there, and are then promoted to the stable tag without a version bump. The beta channel resolves to the newest version by semantic version order from the beta and latest tags, so an older beta tag never replaces a newer stable release. Switching is a single command, openclaw update --channel beta, and the choice is saved to the update channel setting after the core update succeeds.
The tradeoff is plain. A business that handles customer conversations through one assistant is better served by waiting for promotion, since the long-history and retry fixes will arrive on stable without extra work. An operator with a test Gateway, or one whose history has become slow to open, can try the beta there first. The updating documentation is the reference for the update process, and this site’s report on update guardrails lists the checks to run before and after.
A short checklist for operators
- Confirm the current channel before reading any release note as applying to the running Gateway.
- Run
openclaw doctor --fixafter an update so read-cache files from older versions are removed. - After updating, send one message twice to a test channel and confirm only one reply arrives.
- Treat a timed-out tool that changes something outside the assistant as an unknown outcome, and check the real state before repeating it.
- Keep customer-facing and test conversations in separate sessions so a test reply cannot reach a customer.
Readers comparing how different agent systems handle long-running conversations and state can start with the AI agent harness guide, and the OpenClaw chat apps guide covers the channels these fixes apply to.