docs: prune recent additions for readability

docs/channels/irc.md

@@ -237,13 +237,7 @@ Default account supports:
 - `IRC_NICKSERV_PASSWORD`
 - `IRC_NICKSERV_REGISTER_EMAIL`
 
-<Note>
-`IRC_HOST` is on the endpoint-block list and cannot be set from a workspace
-`.env` file. It must come from shell environment or the gateway process
-environment so that untrusted workspaces cannot redirect IRC traffic to a
-different server. See [Workspace `.env` files](/gateway/security) for the full
-list.
-</Note>
+`IRC_HOST` cannot be set from a workspace `.env`; see [Workspace `.env` files](/gateway/security).
 
 ## Troubleshooting
 

docs/channels/matrix.md

@@ -179,13 +179,7 @@ For example, `-` becomes `_X2D_`, so `ops-prod` maps to `MATRIX_OPS_X2D_PROD_*`.
 
 The interactive wizard only offers the env-var shortcut when those auth env vars are already present and the selected account does not already have Matrix auth saved in config.
 
-<Note>
-`MATRIX_HOMESERVER` is on the endpoint-block list and cannot be set from a
-workspace `.env` file. It must come from shell environment or the gateway
-process environment so that untrusted workspaces cannot redirect Matrix
-traffic to a different homeserver. See
-[Workspace `.env` files](/gateway/security) for the full list.
-</Note>
+`MATRIX_HOMESERVER` cannot be set from a workspace `.env`; see [Workspace `.env` files](/gateway/security).
 
 ## Configuration example
 

docs/channels/mattermost.md

@@ -109,13 +109,7 @@ Set these on the gateway host if you prefer env vars:
 
 Env vars apply only to the **default** account (`default`). Other accounts must use config values.
 
-<Note>
-`MATTERMOST_URL` is on the endpoint-block list and cannot be set from a
-workspace `.env` file. It must come from shell environment or the gateway
-process environment so that untrusted workspaces cannot redirect Mattermost
-traffic to a different server. See
-[Workspace `.env` files](/gateway/security) for the full list.
-</Note>
+`MATTERMOST_URL` cannot be set from a workspace `.env`; see [Workspace `.env` files](/gateway/security).
 
 ## Chat modes
 

docs/channels/synology-chat.md

@@ -89,13 +89,7 @@ For the default account, you can use env vars:
 
 Config values override env vars.
 
-<Note>
-`SYNOLOGY_CHAT_INCOMING_URL` is on the endpoint-block list and cannot be set
-from a workspace `.env` file. It must come from shell environment or the
-gateway process environment so that untrusted workspaces cannot redirect
-Synology Chat traffic to a different webhook. See
-[Workspace `.env` files](/gateway/security) for the full list.
-</Note>
+`SYNOLOGY_CHAT_INCOMING_URL` cannot be set from a workspace `.env`; see [Workspace `.env` files](/gateway/security).
 
 ## DM policy and access control
 

docs/cli/gateway.md

@@ -134,8 +134,7 @@ Options:
 
 Notes:
 
-- The recorder is active by default and payload-free: it captures operational metadata only, not chat text, tool outputs, or raw request or response bodies. Set `diagnostics.enabled: false` only when you need to disable Gateway diagnostic heartbeat collection entirely.
-- Records keep operational metadata: event names, counts, byte sizes, memory readings, queue/session state, channel/plugin names, and redacted session summaries. They do not keep chat text, webhook bodies, tool outputs, raw request or response bodies, tokens, cookies, secret values, hostnames, or raw session ids.
+- Records keep operational metadata: event names, counts, byte sizes, memory readings, queue/session state, channel/plugin names, and redacted session summaries. They do not keep chat text, webhook bodies, tool outputs, raw request or response bodies, tokens, cookies, secret values, hostnames, or raw session ids. Set `diagnostics.enabled: false` to disable the recorder entirely.
 - On fatal Gateway exits, shutdown timeouts, and restart startup failures, OpenClaw writes the same diagnostic snapshot to `~/.openclaw/logs/stability/openclaw-stability-*.json` when the recorder has events. Inspect the newest bundle with `openclaw gateway stability --bundle latest`; `--limit`, `--type`, and `--since-seq` also apply to bundle output.
 
 ### `gateway diagnostics export`

docs/cli/plugins.md

@@ -68,12 +68,7 @@ openclaw plugins install <plugin> --marketplace https://github.com/<owner>/<repo
 Bare package names are checked against ClawHub first, then npm. Security note:
 treat plugin installs like running code. Prefer pinned versions.
 
-If your `plugins` section is backed by a single-file `$include`, `plugins install`,
-`plugins update`, `plugins enable`, `plugins disable`, and `plugins uninstall`
-write through to that included file and leave `openclaw.json` untouched. Root
-includes, include arrays, and includes with sibling overrides fail closed
-instead of flattening. See [Config includes](/gateway/configuration) for the
-supported shapes.
+If your `plugins` section is backed by a single-file `$include`, `plugins install/update/enable/disable/uninstall` write through to that included file and leave `openclaw.json` untouched. Root includes, include arrays, and includes with sibling overrides fail closed instead of flattening. See [Config includes](/gateway/configuration) for the supported shapes.
 
 If config is invalid, `plugins install` normally fails closed and tells you to
 run `openclaw doctor --fix` first. The only documented exception is a narrow

docs/gateway/configuration.md

@@ -578,12 +578,8 @@ When you edit a source file that is referenced through `$include`, OpenClaw plan
 the reload from the source-authored layout, not the flattened in-memory view.
 That keeps hot-reload decisions (hot-apply vs restart) predictable even when a
 single top-level section lives in its own included file such as
-`plugins: { $include: "./plugins.json5" }`.
-
-If a reload cannot be planned safely — for example, because the source layout
-combines root includes with sibling overrides — OpenClaw fails closed, logs the
-reason, and leaves the current running config in place so you can fix the source
-shape instead of silently falling back to a flattened reload.
+`plugins: { $include: "./plugins.json5" }`. Reload planning fails closed if the
+source layout is ambiguous.
 
 ## Config RPC (programmatic updates)
 

docs/gateway/openshell.md

@@ -282,18 +282,9 @@ openclaw sandbox recreate --all
 
 ## Security hardening
 
-OpenShell sandbox helpers that read remote workspace files use a pinned file
-descriptor for the workspace root and walk ancestors from that pinned fd
-instead of re-resolving the path for each read. Combined with an identity
-recheck on every operation, this prevents a mid-turn symlink swap or a
-hot-swapped workspace mount from redirecting reads outside the intended
-remote workspace.
-
-- Workspace root is opened once and pinned; later reads reuse that fd.
-- Ancestor walks traverse relative entries from the pinned fd so they cannot
-  be redirected by a replacement directory higher in the path.
-- The sandbox identity is rechecked before each read, so a recreated or
-  reassigned sandbox cannot silently serve files from a different workspace.
+OpenShell pins the workspace root fd and rechecks sandbox identity before each
+read, so symlink swaps or a remounted workspace cannot redirect reads out of
+the intended remote workspace.
 
 ## Current limitations
 

docs/gateway/pairing.md

@@ -131,9 +131,10 @@ auto-approval — they stay as explicit re-approval requests.
 ## QR pairing helpers
 
 `/pair qr` renders the pairing payload as structured media so mobile and
-browser clients can scan it directly. Device deletion now also sweeps stale
-pending pairing requests for the same device id, so `nodes pending` no longer
-shows orphaned rows after a revoke.
+browser clients can scan it directly.
+
+Deleting a device also sweeps any stale pending pairing requests for that
+device id, so `nodes pending` does not show orphaned rows after a revoke.
 
 ## Locality and forwarded headers
 

docs/gateway/security/index.md

@@ -941,16 +941,9 @@ Local device pairing:
   trusted shared-secret helper flows.
 - Tailnet and LAN connects, including same-host tailnet binds, are treated as
   remote for pairing and still need approval.
-- **Forwarded-header evidence disqualifies loopback locality.** If a request
-  arrives on loopback but carries `X-Forwarded-For` / `X-Forwarded-Host` /
-  `X-Forwarded-Proto` headers pointing at a non-local origin, the request is
-  treated as remote for pairing, trusted-proxy auth, and Control UI device
-  identity gating — it no longer qualifies for loopback auto-approval.
-- **Metadata-upgrade auto-approval** applies only to non-sensitive reconnect
-  deltas on already paired trusted local CLI/helper clients that proved
-  possession of the shared token or password over loopback. Browser/Control UI
-  clients and remote clients still require explicit re-approval. Scope upgrades
-  (read to write/admin) and public key changes are never silently upgraded.
+- Forwarded-header evidence on a loopback request disqualifies loopback
+  locality. Metadata-upgrade auto-approval is scoped narrowly. See
+  [Gateway pairing](/gateway/pairing) for both rules.
 
 Auth modes:
 

docs/plugins/architecture.md

@@ -511,10 +511,9 @@ At startup, OpenClaw does roughly this:
 4. normalize plugin config (`plugins.enabled`, `allow`, `deny`, `entries`,
    `slots`, `load.paths`)
 5. decide enablement for each candidate
-6. load enabled native modules — built `dist/*` bundled modules go through a
-   native loader path, while non-built native plugin modules are loaded via
-   jiti
-7. call native `register(api)` (or `activate(api)` — a legacy alias) hooks and collect registrations into the plugin registry
+6. load enabled native modules: built bundled modules use a native loader;
+   unbuilt native plugins use jiti
+7. call native `register(api)` hooks and collect registrations into the plugin registry
 8. expose the registry to commands/runtime surfaces
 
 <Note>

docs/plugins/bundles.md

@@ -261,10 +261,6 @@ dual-format packages from being partially installed as bundles.
   plugins; the release pipeline is responsible for shipping a complete bundled
   dependency payload (see the postpublish verification rule in
   [Releasing](/reference/RELEASING)).
-- Sub-agent runs that launch bundled MCP servers dispose those MCP clients
-  through the shared runtime-cleanup path when the sub-agent exits, so
-  sub-agent lifecycles do not leak stdio child processes or long-lived MCP
-  connections across turns.
 
 ## Security
 

docs/plugins/codex-harness.md

@@ -29,8 +29,7 @@ aligned with the PI harness:
 - `agent_end`
 
 Bundled plugins can also register a Codex app-server extension factory to add
-async `tool_result` middleware, and mirrored Codex transcript writes route
-through `before_message_write`.
+async `tool_result` middleware.
 
 The harness is off by default. It is selected only when the `codex` plugin is
 enabled and the resolved model is a `codex/*` model, or when you explicitly

docs/providers/anthropic.md

@@ -268,11 +268,9 @@ OpenClaw supports Anthropic's prompt caching feature for API-key auth.
 
   </Accordion>
 
-  <Accordion title="Claude Opus 4.7 1M context normalization">
-    Claude Opus 4.7 (`anthropic/claude-opus-4.7`) and its `claude-cli` variant are normalized to a 1M context window in resolved runtime metadata and active-agent status/context reporting. You do not need `params.context1m: true` for Opus 4.7; it no longer inherits the stale 200k fallback.
-
-    Compaction and overflow handling use the 1M window automatically. Other Anthropic models keep their published limits.
-
+  <Accordion title="Claude Opus 4.7 1M context">
+    `anthropic/claude-opus-4.7` and its `claude-cli` variant have a 1M context
+    window by default — no `params.context1m: true` needed.
   </Accordion>
 </AccordionGroup>
 

docs/providers/bedrock-mantle.md

@@ -174,8 +174,6 @@ If you prefer explicit config instead of auto-discovery:
     }
     ```
 
-    Context-window metadata for discovered Mantle models uses known published limits when available and falls back conservatively for unlisted models, so compaction and overflow handling behave correctly for newer entries without overstating unknown models.
-
   </Accordion>
 
   <Accordion title="Relationship to Amazon Bedrock provider">

docs/providers/lmstudio.md

@@ -104,9 +104,11 @@ Interactive setup can prompt for an optional preferred load context length and a
 
 ### Streaming usage compatibility
 
-OpenClaw marks LM Studio as streaming-usage compatible, so token accounting no longer degrades to unknown or stale totals on streamed completions. OpenClaw also recovers token counts from llama.cpp-style `timings.prompt_n` / `timings.predicted_n` metadata when LM Studio does not emit an OpenAI-shaped `usage` object.
+LM Studio is streaming-usage compatible. When it does not emit an OpenAI-shaped
+`usage` object, OpenClaw recovers token counts from llama.cpp-style
+`timings.prompt_n` / `timings.predicted_n` metadata instead.
 
-Other OpenAI-compatible local backends covered by the same behavior:
+Same behavior applies to these OpenAI-compatible local backends:
 
 - vLLM
 - SGLang

docs/providers/moonshot.md

@@ -349,9 +349,9 @@ Config lives under `plugins.entries.moonshot.config.webSearch`:
   </Accordion>
 
   <Accordion title="Tool call id sanitization">
-    Moonshot Kimi serves native tool_call ids shaped like `functions.<name>:<index>` on the OpenAI-compatible transport. OpenClaw no longer strict-sanitizes these ids for Moonshot, so multi-turn agentic flows through Kimi K2.6 keep working past 2-3 tool-calling rounds when the serving layer matches mangled ids against the original tool definitions.
+    Moonshot Kimi serves tool_call ids shaped like `functions.<name>:<index>`. OpenClaw preserves them unchanged so multi-turn tool calls keep working.
 
-    If a custom OpenAI-compatible provider needs the previous behavior, set `sanitizeToolCallIds: true` on the provider entry. The flag lives on the shared `openai-compatible` replay family; Moonshot is wired to the opt-out by default.
+    To force strict sanitization on a custom OpenAI-compatible provider, set `sanitizeToolCallIds: true`:
 
     ```json5
     {

docs/web/control-ui.md

@@ -78,18 +78,12 @@ you revoke it with `openclaw devices revoke --device <id> --role <role>`. See
 
 ## Personal identity (browser-local)
 
-The Control UI supports a per-browser personal identity — a display name and
-avatar that are attached to outgoing messages for attribution in shared
-sessions. This identity lives in browser storage, is scoped to the current
-browser profile, and does not leave the gateway host unless you explicitly
-submit it with a request.
-
-- Identity is **browser-local only**. It is not synced to other devices and is
-  not part of the gateway config file.
-- Clearing site data or switching browsers resets the identity to empty; the
-  Control UI does not try to reconstruct one from server state.
-- Nothing about the personal identity is persisted server-side beyond the
-  normal transcript authorship metadata on messages you actually send.
+The Control UI supports a per-browser personal identity (display name and
+avatar) attached to outgoing messages for attribution in shared sessions. It
+lives in browser storage, is scoped to the current browser profile, and is not
+synced to other devices or persisted server-side beyond the normal transcript
+authorship metadata on messages you actually send. Clearing site data or
+switching browsers resets it to empty.
 
 ## Runtime config endpoint
 
@@ -97,9 +91,7 @@ The Control UI fetches its runtime settings from
 `/__openclaw/control-ui-config.json`. That endpoint is gated by the same
 gateway auth as the rest of the HTTP surface: unauthenticated browsers cannot
 fetch it, and a successful fetch requires either an already valid gateway
-token/password, Tailscale Serve identity, or a trusted-proxy identity. This
-keeps Control UI feature flags and endpoint metadata from leaking to
-unauthenticated scanners on shared hosts.
+token/password, Tailscale Serve identity, or a trusted-proxy identity.
 
 ## Language support