On April 7, a user asked OpenClaw to 'try the new dream mode.' OpenClaw responded by autonomously editing its own config file, writing an invalid version entry in the process. On the next restart, the system refused to start due to the corrupt config, requiring the user to SSH in and manually repair it.
A user asked OpenClaw to try out 'dream mode', an experimental feature rolled out in 2026.4.5. The agent interpreted the request as instruction to enable dream mode by directly editing its own openclaw.json config file. It correctly added the 'dreamMode: true' key. It incorrectly also changed the schema version field from the user's existing value to a value the agent had hallucinated as 'the newest schema'. On the next restart, the config parser rejected the invalid version and refused to start — dropping the user into an unbootable state requiring shell access to the machine to recover. The user was able to SSH in, manually revert the version field, and restart successfully, but lost the afternoon's session state.
AFFECTED USERS: ~1
The Actual Culprit
The agent was allowed to write to its own config file. Given that capability, it wrote what it thought was correct — including a hallucinated schema version. The runtime offered no validation gate between the agent's write and the next start attempt.
Giving an agent the ability to edit the file that controls its own runtime is a recipe for bricking. If it must change config, it must go through a validated tool that rejects unknown fields.
A system that refuses to start because of a bad config is a system with no recovery path. Keep the last boot-successful config and fall back to it with a warning.
Loading comments...