OpenClaw Main Repairs Two Hidden-Output Boundaries

OpenClaw has merged two corrections for data that an operator explicitly chose not to expose. One closes a P1 model-context leak involving private shell history; the other stops Telegram verbose mode from overriding disabled tool-progress delivery.

The common lesson is important: hidden is a policy decision, not a rendering preference. Every later consumer must preserve it. These changes are on main; confirm the first containing release before treating an installed package as repaired.

Private shell output could re-enter model context

OpenClaw can persist a bashExecution record with excludeFromContext: true. The intended contract is useful: retain owner-visible execution evidence without sending the output back to a model.

PR #121147 found that the final provider conversion filtered those records in some paths, but shared consumers earlier in the pipeline did not. A private shell record could still:

• appear in replayed model context;
• enter compaction or branch-summary prompts;
• count against token estimates;
• influence the retained-history cut boundary; or
• be mirrored into Codex session history.

That is more than wasted context. Shell output routinely contains filesystem paths, source fragments, process details and command results that the operator deliberately marked unavailable to the model.

The landed fix moves the rule to the shared session projection owner. Context-excluded shell rows remain in raw persisted history, but are omitted from model-visible projection. Compaction gives them zero token cost and prevents them from becoming a retained cut boundary. Ordinary visible shell output is unchanged.

Interpretation: filtering only at the provider adapter was structurally too late. Replay, summarisation and compaction are themselves model-input producers, so they need the same authoritative projection.

This is not retroactive deletion

The patch deliberately does not remove persisted bytes. That preserves owner audit history, but it means an upgrade cannot erase earlier provider requests, branch summaries or mirrored history that may already contain private output.

If a pre-fix deployment used context-excluded shell execution:

1. identify the sessions and exact source revisions involved;
2. preserve lawful audit evidence before changing retention;
3. inspect provider and session telemetry for actual model-visible transmission;
4. rotate credentials only when evidence indicates exposure, rather than assuming every shell record contained a secret;
5. upgrade to a confirmed containing build; and
6. test with harmless canary output before restoring sensitive workflows.

Do not paste real shell transcripts into tickets to prove the bug.

Telegram verbose mode also overrode a hidden-output choice

PR #121395 fixes a narrower but user-visible policy conflict. Telegram users could disable tool progress, then enable /verbose and still receive internal commentary or tool messages.

Telegram now resolves tool-progress visibility once per turn and passes a hard suppression fact into the shared reply dispatcher. Verbose mode may add progress only when the channel configuration permits progress. Durable and final replies retain their existing behavior.

This distinction matters in shared or operational chats. Verbose mode should never silently broaden a channel-level disclosure policy.

Acceptance tests

Use synthetic, non-sensitive fixtures on a staging Gateway:

Shell projection

1. create one visible shell result and one excludeFromContext: true result with unique canaries;
2. continue the session and inspect the model-visible request projection;
3. trigger compaction and branch summarisation;
4. verify the private canary is absent from replay, summaries, Codex mirroring, token accounting and retained-cut selection;
5. verify the raw owner-visible history still contains it; and
6. verify the ordinary visible canary still behaves normally.

Telegram delivery

1. disable Telegram tool progress;
2. enable /verbose;
3. run a harmless tool-producing turn;
4. require no standalone commentary, plan or tool-progress messages;
5. confirm the final reply still arrives; and
6. re-enable configured progress and prove verbose output returns only then.

A missing final reply is not a passing privacy test; it is a delivery regression.

Bottom line

OpenClaw now applies both controls at the owners that can enforce them across downstream paths. Prioritise a containing build if you rely on private persisted shell history or Telegram progress suppression, then verify the negative path with canaries rather than trusting one UI toggle.