OpeClaw Platform and Permission Boundary Update

A local AI assistant still needs permission boundaries

“Running on your own machine” can be useful, but it should not become an absolute privacy claim or imply that the assistant can operate the computer without clear user authorization. A better description is that OpeClaw-style workflows organize local configuration, model requests, prompts, and selected automation steps.

The closer a workflow gets to local files and scripts, the more carefully users should check what is being authorized. A responsible download site should explain source, platform, permissions, and model-service boundaries instead of replacing them with broad safety claims.

Four boundaries to verify before setup

• Platform boundary: Windows, macOS, and Linux notes may differ. Do not copy one platform's status to another.
• Source boundary: use the current download page, project notes, and verifiable release status rather than reposted installers.
• Model boundary: when a cloud model is connected, relevant prompt content may enter that provider's processing scope.
• Permission boundary: file access, script execution, and chat-entry authorization should be reviewed one by one.

What changed across the site

The download page, FAQ, troubleshooting notes, and writing workflow resources now use the same editorial rule: explain current status first, then explain what a user should verify. Unverified capabilities should not be written as facts.

If you are deciding whether OpeClaw fits your workflow, start with the download status page, then check the FAQ and related troubleshooting resources. That is more useful than a single “supported platform” sentence.