Early install (pre sandbox I *think*) barely works now. Can someone ELI5 the sandbox?

[celest bloom]

My first agent had full disk priv’s at install and it was practically unstoppable. Now I can’t accomplish the kind of self improvement I was able to do before. I’d be very grateful to have a conversation about the sandbox limitations (and config options) to see if I can get back some of the functionality I had working before. TIA

[tardy river]

Hey andyml_! 👋

Great question — the sandbox is probably what's slowing you down. Here's the ELI5:

What the Sandbox Does

When enabled, tools (exec, read, write, edit, etc.) run inside isolated Docker containers instead of on your host. This limits what the agent can touch.

The 3 Key Settings

1. mode — When sandboxing applies:

   • "off" = no sandbox (full host access, like your old setup 🦾)
   • "non-main" = sandbox only non-main sessions (default)
   • "all" = sandbox everything

2. scope — How many containers:

   • "session" = one container per session (default)

• "agent" = one container per agent
  • "shared" = one container for all

3. workspaceAccess — What the sandbox can see:
   • "none" = isolated temp workspace (most locked down)
   • "ro" = read-only access to your actual workspace
   • "rw" = full read/write access to your workspace

Getting Your "Unstoppable" Agent Back

If you want the old behavior back, add this to your config:

{
  agents: {
    defaults: {

      sandbox: {
        mode: "off",           // Disable sandbox entirely
        workspaceAccess: "rw"  // Or if keeping sandbox: full rw access
      }
    }
  }
}

Or for a per-agent override:

{
  agents: {
    list: [
      {

        id: "main",
        sandbox: {
          mode: "off"
        }
      }
    ]
  }
}

Less Drastic Options

If you want some sandboxing but still want self-improvement capability:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",      // Only sandbox group chats, keep DMs on host
        scope: "agent",        // Reuse containers for stability
        workspaceAccess: "rw"  // Full read/write access
      }
    }
  }
}

Check Your Current Settings

Run this to see what's actually active:

clawdbot sandbox explain

This will show you the effective mode, scope, workspace access, and tool policy — plus the config keys to fix anything.

---

Bottom line: If you want your agent to be "unstoppable" again, sandbox.mode: "off" or sandbox.workspaceAccess: "rw" is your friend. Just be aware that gives the model full access to your filesystem again. 🦐

Let me know if you need help with the specific config!

[celest bloom]

Man. I think that was it.

[tardy river]

Hey andyml_! 🦐 Let me ELI5 the sandbox for you.

The Short Version:
Sandboxing runs your agent's tools inside Docker containers instead of directly on your host. This limits what the agent can access (filesystem, processes, network) — great for security, annoying when you need full access.

Three Main Controls:

1. agents.defaults.sandbox.mode — When to sandbox:

   • "off" = no sandbox (what you had before, full host access)
   • "non-main" = sandbox only group/channel sessions, keep main session on host (default)
   • "all" = sandbox everything

2. agents.defaults.sandbox.workspaceAccess — What the sandbox can see:

   • "none" = sees only its own temporary workspace (most locked down)
   • "ro" = can read your agent workspace but not write
   • "rw" = full read/write access to your workspace

3. tools.elevated — Escape hatch for exec commands that need host access

To Get Your Old Power Back:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "off"           // Disable sandbox entirely
        // OR for per-agent:
        // mode: "all",
        // workspaceAccess: "rw"
      }
    },
    list: [

      {
        id: "your-agent",
        sandbox: {
          mode: "off"  // Per-agent override
        }
      }
    ]
  }
}

Or More Granular (keep sandbox but open it up):

{

  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        workspaceAccess: "rw",  // Give full workspace access
        docker: {
          binds: [
            "/your/path:/path:rw"  // Mount specific dirs you need
          ]
        }
      }
    }
  }
}