# v0.2.2: Remote Memory Space Activation

[简体中文](../../zh-CN/releases/v0.2.2.md) | **English** | [Capability map](../capabilities.md)

v0.2.2 fixes Memory Space activation from a remote trusted DSH page and tightens the surrounding RPC authority boundaries.

## Fixed

- Activating or deactivating a Memory Space now uses the dedicated trusted-host `/dsh-mnemon-activation` control channel instead of the loopback-only general write channel.
- The activation handler accepts only a Memory Space ID, a Boolean active state, and normal session/workspace routing fields. Metadata, Provider configuration, credentials, deletion, and durable-memory writes cannot cross this boundary.
- The client falls back to the legacy write endpoint only when an older Host reports the new activation endpoint as missing. It does not retry a `403` or any business failure through a broader channel.
- Remote WebUI sessions keep activation available while disabling edit, delete, reconnect, memory distillation, document/runtime mutation, version update, settings, backups, and Provider configuration before transport.

## Authority audit

- The trusted-host Provider service catalog is now redacted and never returns saved credential values.
- Private Provider settings remain available to the local settings editor only through the loopback write channel.
- Message save actions, settings, backup import/export, Provider service controls, and version updates all apply the same loopback preflight rule.

## Compatibility and upgrading

Update dsh-mnemon and restart the affected DSH profile. On loopback connections, the browser client remains compatible with pre-v0.2.2 Hosts for activation and private Provider catalog reads through narrow missing-endpoint fallbacks; remote activation requires the updated Host boundary. This patch does not migrate, rewrite, or delete Runtime Memory, Project Documents, Memory Spaces, or Provider data.

See the [v0.2.1 release notes](./v0.2.1.md) for the previous patch release.