OpenClaw Adds Incognito Chats and Enforced Session Sharing on Main
OpenClaw's new session model separates ephemeral chats, private drafts, read-only work and named collaboration—with enforcement at the Gateway rather than only in the UI.
OpenClaw has merged two different kinds of session privacy into main: incognito sessions, whose conversation content lives only for the Gateway process lifetime, and sharing controls, which decide who can see or act on a durable session.
They solve different problems. Incognito is about persistence. Visibility and membership are about participation. Operators should not treat either one as a magic confidentiality switch.
The operator decision
| Need | Use | Important limit |
|---|---|---|
| Avoid storing a web conversation in OpenClaw session or memory state | Create an incognito session from the web Control UI | The model provider and ordinary tools still process data; the Gateway owner can observe the process |
| Keep work in progress out of teammates’ normal session view | Create a draft | Admins can still administer drafts; promotion makes the session shared |
| Let people inspect but not drive a session | Set it read-only | Enforcement depends on the Gateway version carrying these merges |
| Limit participation to named collaborators | Use restricted membership | Do not rely on a UI-hidden composer; the server-side participation check is the real boundary |
| Prevent a send from silently landing on a branch switched elsewhere | Use a client that supplies the new leaf precondition | Older clients may omit the additive precondition |
These changes were merged on 23 July. Check the release or source revision you actually run for PRs #112787, #113006, #113023, #113073 and #113127; a feature existing on main does not prove every installed package or client implements it.
Incognito means process-memory session storage
PR #113006 adds an Incognito choice to the web Control UI’s new-thread flow. It is immutable at creation: OpenClaw cannot honestly label an existing durable transcript ephemeral after it has already written history.
The session uses an in-memory SQLite database with the normal session schema. According to the merged implementation, conversation content does not enter the durable session tables, automatic memory flushing is disabled, LanceDB capture is skipped, and an explicit memory_store attempt is rejected. Child sessions inherit incognito treatment so a subagent cannot casually flow conversation content back into a durable parent transcript.
A Gateway restart destroys the in-memory session. Just as importantly, a stale incognito key fails closed after restart instead of falling through to a durable store and accidentally recreating the conversation as persistent.
Upstream reports a live browser-and-model test that found no session rows, transcript rows, memory copy or Codex rollout file after the turn. That is upstream evidence; OpenClaw Academy has reviewed the merged source record but has not independently repeated the live test.
What incognito does not promise
The agent retains its normal tools. A tool can still send data to an external service or write it somewhere its policy permits. The model provider still receives the request. Content-free audit metadata may remain. The process owner remains in a privileged position.
Interpretation: incognito narrows OpenClaw-owned retention. It is not an anonymous-computing mode, a provider no-retention contract or a substitute for tool restrictions.
Use it for conversations that should not become ordinary OpenClaw history. Do not use it to justify putting secrets into prompts or granting broad tools.
Durable sessions gain actual participation policy
PR #112787 adds four visibility states—shared, read-only, suggest and draft—plus owner-managed membership. The material point is where enforcement happens: the Gateway authorizes session-mutating methods against the resolved session, rather than trusting the Control UI to hide buttons.
Non-participants cannot send, steer, abort, approve or edit files in a restricted session. Drafts are hidden from non-owners and non-admins. Single-user Gateways retain the previous shared-session behaviour.
Sharing state binds to a specific session instance, not merely its reusable key. PR #113023 closes a race in which a request authorized against an old shared session could otherwise mutate a replacement draft or read-only session created under the same key. Writers now revalidate the session identity and participation policy at the mutation boundary.
That is the right security model: authorization should attach to the object instance that was reviewed, not whatever later occupies the same address.
Drafts no longer flicker through shared state
The initial visibility work made new sessions shared before an owner could change them. PR #113127 adds atomic create-as-draft support so private work is never briefly exposed as shared.
The Control UI offers the option only where policy permits drafts and the Gateway reports a multi-identity environment. Owners can promote a draft to shared in one action, while admins viewing another user’s draft receive a distinct ghosted treatment.
Draft is therefore a collaboration state, not an ephemeral state. Its content remains durable. If the requirement is “do not write this conversation to OpenClaw storage,” use incognito instead.
The last documented branch-switch race was closed for the web sender
Our earlier analysis of native branch switching documented a remaining cross-client race: one pane could send against branch X after another client switched the active session to branch Y.
PR #113073 adds an optional expectedLeafEntryId to chat.send. The web pane sends the leaf it actually rendered—not merely the latest branch value fetched in the background. The Gateway checks that precondition inside the same locked admission boundary used for branch switching.
On mismatch, the send is rejected with a typed active-leaf-changed reason, the draft is restored, and the UI asks the operator to review and resend. Upstream reports a two-tab live test proving the stale send produced zero server-side writes.
Because the field is additive, clients that do not send it retain previous behaviour. Mixed-client operators should therefore verify client support before treating this as a universal cross-client guarantee.
A practical acceptance test
After adopting a release containing this cluster, use disposable content and verify:
- an incognito turn disappears after Gateway restart and cannot be resumed by stale key;
- session and memory searches cannot recover its conversation text;
- a non-member cannot mutate a restricted session through direct Gateway calls;
- resetting and recreating a restricted key does not carry old membership forward;
- a draft is private from creation, not shared first and hidden later; and
- a stale web pane receives review-and-resend rather than writing to a switched branch.
Do not test ephemerality with real secrets. Prove the boundary with a unique harmless marker.
Bottom line
OpenClaw’s session model is becoming meaningfully multi-user: ephemeral chats, durable drafts, read-only work and named participation now have distinct semantics and server-side enforcement.
The sharp edge is terminology. Incognito controls OpenClaw persistence; draft controls collaboration visibility. Neither removes model-provider processing, tool side effects or host-owner privilege. Adopt the controls only after confirming the exact release and testing the boundary you actually need.
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