Summary

When an agent fails to start due to a sandbox security violation (e.g., a bind mount source outside allowed roots), the full error message is posted to the configured channel as if it were the agent's reply. This leaks internal file paths, usernames, config file locations, and potentially PII to public-facing channels like Discord.

Steps to reproduce

1. Configure an agent with a sandbox bind mount where the source path is outside the allowed workspace root
2. Send a message that triggers the agent (e.g., via Discord channel routing)
3. The agent fails before generating a reply

Expected behavior

The error should be logged internally (visible via openclaw logs --follow) but never posted to the channel. The channel should either receive no reply or a generic "Something went wrong" message.

Actual behavior

The full error is posted as a message to the channel:

⚠️ Agent failed before reply: Sandbox security: bind mount "/home/user/.openclaw/sandbox-configs/config.json:/app/config.json:ro" source "/home/user/.openclaw/sandbox-configs/config.json" is outside allowed roots (/home/user/.openclaw/workspace-agent). Use a dangerous override only when you fully trust this runtime.
Logs: openclaw logs --follow

This exposes:

• Full filesystem paths including the OS username
• Sandbox configuration details
• Workspace directory structure
• Config file names and mount targets

Impact

• PII exposure: OS usernames embedded in paths are visible to anyone in the channel
• Security posture leak: Attackers/observers learn the exact sandbox configuration, allowed roots, and filesystem layout
• Trust erosion: Community members see raw infrastructure errors instead of a graceful failure

Related

• [Bug]: Announce delivery posts raw error JSON to channels when cron run fails #42243 covers a similar pattern for cron announce delivery posting raw errors. This is the agent-reply equivalent — the sandbox preflight error becomes the channel message.

Suggestion

• Agent preflight failures (sandbox, config, auth) should never be forwarded to the channel
• Log the full error to openclaw logs for operator debugging
• Optionally post a generic "I'm having trouble right now — check logs" or stay silent
• Consider redacting paths in all user-facing error surfaces as defense-in-depth