夜雨聆风OpenClaw v2026.4.12-beta.1 修了一个安全问题。
说是"修了"，其实是加了一层强制检查——如果你部署 OpenClaw 时直接沿用了示例配置文件里的默认密码，现在启动会直接失败，拒绝运行。
问题的背景
OpenClaw 的 .env.example 是一个模板文件，告诉用户需要配哪些变量。其中包括 GATEWAY_TOKEN 和 GATEWAY_PASSWORD 这类认证凭据。
问题是，这类示例文件通常会写一个明显的占位符，比如 your-token-here 或者 changeme。但并不是所有用户都会注意到"你需要修改这个"。
更糟糕的是：这个文件是公开的，在 GitHub 上任何人都能看到。
如果有人搭了 OpenClaw、没改默认凭据、又把服务暴露在公网上——攻击者只需要拿着 GitHub 上的示例文件，就能直接接管这个网关。
这次修了什么
两个改动：
一、清空示例文件里的凭据
.env.example 里的示例 token 和密码全部改为空值。新用户必须自己填写，不存在可以直接复制粘贴的"可用但危险"的默认值。
二、启动时强制校验
如果 OpenClaw 检测到配置中使用的 token 或密码，和已知的占位符值相同（这个版本之前 .env.example 里的那个值），会拒绝启动，抛出明确的错误提示，要求用户先修改。
这意味着你不能再靠"先跑起来再说"蒙混过关了。
这类问题有多普遍
这不是 OpenClaw 独有的问题。整个开源生态里，默认密码导致的安全事故从没停过。
常见的模式：
- ▶数据库默认密码（MongoDB 早年无密码直接对外暴露，导致大量数据库被清空勒索）
- ▶管理面板默认账号（admin/admin、admin/password）
- ▶API token 直接写在代码里提交到 GitHub
OpenClaw 这次的修法属于"防御性设计"——不是靠文档提醒，而是靠系统强制拦截。
Telegram 内部信息泄露问题
这个版本还修了另一个和信息隔离有关的问题。
在 Telegram 场景下，如果你用 Codex 或其他 ACP harness 运行任务，任务过程中会有一些"内部规划阶段"的 commentary 文本。这些文本是 AI 的内部工作过程，不应该展示给用户。
但之前有一个路径漏掉了：这些 commentary 文本会在某些条件下直接发送到 Telegram DM。
现在对 Telegram direct session 的 delivery 逻辑加了过滤，commentary-only 的 fallback payload 不再走 direct delivery 渠道。
简单说：AI 的内部思考，不该出现在用户的 Telegram 消息里。
插件权限边界的收紧
这个版本对插件加载机制做了较大改动，插件只能访问自己 manifest 里声明的资源，不能跨越到其他插件的运行时域。
这不只是性能优化——这是权限隔离。一个行为异常或恶意的插件，现在更难影响到其他插件的运行环境。
对普通用户的意义
如果你是自部署用户：检查你的 .env 文件，确认 GATEWAY_TOKEN 和 GATEWAY_PASSWORD 是你自己设的值，不是从示例文件里复制粘贴来的。
如果你是云端托管用户：这类问题通常由平台处理，但了解一下总没坏处。
如果你在开发插件：这个版本的 manifest 权限声明要求更严格了，旧的插件可能需要更新 manifest 才能正常加载。
