Three OpenClaw Main Boundary Fixes Protect Profiles, Audio and Telegram DMs
Managed updates could finalise against the caller's profile, chat history could expose raw audio or local paths, and Telegram DM tool policy could be skipped on queued or native runs.
OpenClaw has merged three security-relevant boundary repairs into main: a managed Gateway update now stays attached to the service owner’s profile, persisted audio is redacted before authenticated history delivery, and Telegram direct-message tool restrictions survive queued and native execution paths.
None is a published CVE in the supplied evidence. All three deserve operator attention because each defect let authority or data cross an internal boundary that configuration appeared to protect.
Release boundary: these fixes are merged on main. Track the release containing each change; do not assume an installed package is protected because the pull request is closed.
1. Managed updates stay in the owned profile
PR #113901 addresses a profile-confusion path. Updating an owned managed Gateway from a shell using another OpenClaw profile could finalise against the shell’s configuration and plugin state. The fresh child inherited the caller’s environment, fallback logic read and mutated the caller profile, and plugin records could be loaded before service ownership was resolved.
The merged fix scopes finalisation to the managed service’s profile and removes the stale environment import.
This matters on hosts that deliberately separate production, staging, personal or customer Gateways. A profile boundary is supposed to keep configuration, plugins and state from bleeding between those roles; an updater that follows the invoking shell defeats that isolation at the worst possible moment.
Action: before and after a containing upgrade, record the managed service’s profile, state directory, enabled plugins and service definition. Invoke an update from a shell set to a different disposable profile, then prove that only the owned Gateway’s expected version and state changed. Do not perform the first cross-profile test on production.
If a previous update may have crossed profiles, preserve both state directories and compare configuration and plugin records before “cleaning up.” Blindly copying one profile over another destroys evidence and may compound the damage.
2. Chat history strips raw audio and host-local references
PR #121109 fixes persisted audio blocks reaching authenticated WebSocket and HTTP/SSE history clients with raw bytes or host-local references. Affected forms included top-level data, non-string source.data, and filesystem-backed URL or path values.
The repair moves redaction to the shared chat-display projection used by both history transports. Remote and managed media references are preserved; raw payload bytes and local filesystem references are removed.
Authentication did not make the old output appropriate. A history reader may be allowed to view a conversation without needing bulk audio bytes or knowledge of the host’s filesystem layout.
Action: upgrade every Gateway that persists audio, then query history through each enabled client using synthetic media. Confirm the transcript remains intelligible while base64/blob data, file: references and local paths are absent. Review old exports, browser caches, logs and support bundles separately—the fix cannot retract previously copied history.
If real audio or sensitive paths were exposed beyond their intended readers, preserve access evidence and follow the applicable incident process. Do not publish samples to prove the problem.
3. Telegram DM policy follows the run
Commit 409fb7a enforces configured Telegram direct-message tool policies across queued runs and native harnesses. Unsupported restricted harnesses now refuse visibly; turns without an explicit policy keep their existing tool access.
That last distinction matters. The patch repairs enforcement of configured restrictions; it does not introduce a global deny-by-default policy for every Telegram DM.
PR #121117 closes a related topic-identity mismatch. Telegram and grammY distinguish the direct-message topic identity from message_thread_id. Authorization and configuration selection now carry the canonical DM topic identity used by delivery.
Action: test one explicitly restricted DM topic through immediate, queued and native-harness routes. Attempt a harmless denied tool and require a visible refusal in every path. Then test another topic/account with different policy to prove that routing and authorization use the same identity.
Do not test with a destructive tool merely because it should be denied. Use a synthetic capability whose invocation is observable and harmless.
Priorities
- Upgrade Gateways that expose chat history to multiple authenticated clients or persist sensitive audio.
- Validate managed multi-profile hosts before their next update operation.
- Re-test Telegram DM topic policies across all execution paths, especially queues and native harnesses.
- Preserve historical artifacts if you suspect profile mutation or history disclosure; remediation should not erase chronology.
Bottom line
These fixes reinforce the same rule at three layers: the owner selected by policy must remain the owner through update, projection and execution. Adopt the containing releases, then test the boundary from the least-trusted legitimate caller—not only from an administrator’s happy path.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF