#7851: feat: secure sandbox defaults for new installs

#7827 ### Summary This PR introduces a safer sandbox default for new installations, aligning runtime behavior and examples with the “reasonably safe” posture described in the gateway security/sandboxing docs, without changing behavior for existing configs. ### What’s changed 1. **Conditional secure sandbox defaults** In the config defaulting pipeline (`src/config/defaults.ts`), `agents.defaults.sandbox` now gets a secure default **only when it is missing**: - `mode: "non-main"` – sandbox non-main sessions by default. - `scope: "session"`. - `workspaceAccess: "none"` – no host workspace access unless explicitly enabled. - `docker.network: "none"` – no outbound network from sandbox containers by default. If the user provides any `agents.defaults.sandbox` object, their values are preserved as-is and nothing is overridden. 2. **Docs and example config updates** - `docs/gateway/configuration.md`: updated the `~/.openclaw/agents.json5` example to include the above sandbox block as the **recommended secure default for new installs**, with short inline comments explaining each field. - `docs/gateway/sandboxing.md`: updated the minimal example to: - include `docker.network: "none"`, - clearly label this configuration as the recommended starting point for “reasonably safe” deployments. 3. **Tests** - Added `src/config/agent-sandbox-defaults.test.ts` to lock in the behavior: - when `agents.defaults.sandbox` is absent, the secure defaults are injected; - when any `agents.defaults.sandbox` is present, it is preserved and not modified. ### Non-goals - No changes to `dmScope` / DM isolation presets. - No changes to public/untrusted agent profiles or tool allow/deny policies. - No changes to existing user configs on disk; this only affects configs that omit `agents.defaults.sandbox` and the new-install documentation examples. ### Rationale The security docs already recommend running with sandboxing, non-root containers, no network egress from the sandbox, and isolated workspaces for most real deployments. This PR makes that posture easy to get by default for new setups, while keeping existing installations and advanced operators’ custom configs untouched. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates the config defaulting pipeline so that `agents.defaults.sandbox` gets a secure baseline **only when the sandbox block is missing**, leaving any user-provided sandbox config untouched. It also updates the gateway docs/examples to recommend that baseline for new installs, and adds a Vitest to lock in the “inject when absent / preserve when present” behavior. The changes fit into the existing defaults pattern in `src/config/defaults.ts` (mutate-on-demand with early returns), extending agent defaults to include sandbox posture alongside the existing concurrency defaults. <h3>Confidence Score: 5/5</h3> - This PR looks safe to merge with minimal risk. - Changes are localized to config defaulting, guarded to only apply when sandbox config is absent, and covered by a focused unit test; docs/examples align with the new defaults. - No files require special attention <!-- greptile_other_comments_section --> _{(4/5) You can add custom instructions or style guidelines for the agent [here](https://app.greptile.com/review/github)!} <!-- /greptile_comment -->