Openclaw 配置踩坑

我喜欢使用docker来部署，防止失控， 默认的openclaw.json配置中关于agent.defaults.sandbox.mode默认为”non-main”, 如果同时设置了sandbox.workspaceRoot目录，然后在agent.id=”main”中同时设置了workspace目录位置。 我的本意是，agent为main的，都使用这个指定的workspace目录。如果使用docker部署，同时在不同的聊天渠道下，有时候会 把sandbox.workspaceRoot/session 下的目录作为workspace目录，从而整个错乱了。

openclaw给出的解释:

根据 OpenClaw 文档和 schema 设计：
sandbox.mode: "non-main" 表示：非 main agent 的会话默认启用沙箱，main agent 默认不启用。
这是一个全局默认值（fallback），不是强制规则。
矛盾点：为什么 main agent 在沙箱里？
因为 OpenClaw 的运行时逻辑是：
sandbox.mode: "non-main" = 除了 main 以外的 agent 默认进沙箱。但 Gateway 本身是否把 main 也放进沙箱，取决于 agents.defaults.sandbox 的其他字段（如 workspaceRoot、docker.image 等）是否存在。
当 defaults.sandbox 块完整存在（有 workspaceRoot、browser.allowHostControl 等），Gateway 会把它当作一个有效的沙箱配置模板，即使 mode 是 "non-main"，main agent 如果也被 Docker 包装了，就会继承这个模板。

因此，对于agent.id=”main”的配置，如果不使用sandbox的话（即使它真的运行在docker中）， 依然要配置”sandbox”: { “mode”: “off” } 来覆盖默认值。

我的两个agent(test1, test2), 两个配置基本一致，通过backend=ssh连接到其他的服务器（也是docker构建的，主要是因为默认的docker沙箱无法打开端口和高权限操作），然后我在同一个matrix房间中，分别询问这两个agent 的workspace的全路径， 然后，一个告诉我在/workspace，一个告诉我在/workspace/<session-id>/workspace, 最后让openclaw查询官方文档才找出区别:

完全是workspaceAccess模式的不同