Workspace Question

[burnt plover]

Hi there,

Trying to figure out how I can change the active workspace such that I can install a skill in a specific agent's workspace only.

[dim oar]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[glacial ether]

Short version: for a skill that should exist in one agent only, put/install it in that agent’s workspace skills/ folder.

A couple important details:

• Each agent can have its own workspace via agents.list[].workspace
• Per-agent skills live in <that-workspace>/skills
• Shared skills for all agents live in ~/.openclaw/skills

The slightly confusing bit: today, openclaw skills install <slug> targets the default agent workspace. There isn’t a --agent flag on that command right now.

So your options are:

1. Best: install/copy the skill directly into the target agent workspace
   ~/.openclaw/workspace-myagent/skills/<skill-name>/SKILL.md

2. Use clawhub with an explicit workdir
   clawhub --workdir ~/.openclaw/workspace-myagent install <slug>

3. Temporarily make that agent the default, run openclaw skills install <slug>, then switch it back

If you want, paste:

• openclaw --version
• your agents.list config block

and I can tell you the exact path/command for your setup.

Docs:

• https://docs.openclaw.ai/tools/skills
• https://docs.openclaw.ai/concepts/agent-workspace
• https://docs.openclaw.ai/cli/agents
• https://docs.openclaw.ai/tools/clawhub

[burnt plover]

ok, ended up using 2. for now, thank you

now in talking to the main agent it says "this sandbox doesn’t have the gog binary installed"

[glacial ether]

Yep, that tracks.

clawhub install only copied the skill folder. It did not install the actual gog binary. And for a sandboxed agent, gog has to exist inside the sandbox too.

Quick checks:

which gog
openclaw sandbox explain --agent main

What to do next:

1. If which gog fails, install gog on the host first
   (the skill’s installer metadata is not run by clawhub install / openclaw skills install).

2. If host has gog, but the agent still complains, then the sandbox image/container is missing it.

You’ve got 2 sane options:

• Recommended: keep sandboxing, add gog to the sandbox image or agents.list[].sandbox.docker.setupCommand, then:

  openclaw sandbox recreate --agent main
  

• Simpler: disable sandbox for that agent with:

  { agents: { list: [{ id: "main", sandbox: { mode: "off" } }] } }
  

One gotcha: setupCommand only works if the sandbox has network egress, writable root, and root user.

If you want, paste these and I’ll point to the exact fix:

openclaw --version
which gog
openclaw sandbox explain --agent main

Docs:

• https://docs.openclaw.ai/tools/skills
• https://docs.openclaw.ai/gateway/sandboxing
• https://docs.openclaw.ai/cli/sandbox

[burnt plover]

openclaw --version
which gog
openclaw sandbox explain --agent personal
OpenClaw 2026.4.15 (041266a)
/usr/local/bin/gog

🦞 OpenClaw 2026.4.15 (041266a) — Greetings, Professor Falken

Effective sandbox:
agentId: personal
sessionKey: agent:personal:main
mainSessionKey: agent:personal:main
runtime: sandboxed
mode: all scope: session
workspaceAccess: rw workspaceRoot: /home/ubuntu/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, feishu, googlechat, nostr, msteams, mattermost, nextcloud-talk, matrix, bluebubbles, line, zalo, zalouser, synology-chat, tlon, discord, imessage, irc, qqbot, signal, slack, telegram, twitch, whatsapp

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

Fix-it:

• agents.defaults.sandbox.mode=off
• agents.list[].sandbox.mode=off
• tools.sandbox.tools.allow
• tools.sandbox.tools.alsoAllow
• tools.sandbox.tools.deny
• agents.list[].tools.sandbox.tools.allow
• agents.list[].tools.sandbox.tools.alsoAllow
• agents.list[].tools.sandbox.tools.deny
• tools.elevated.enabled

Docs: docs.openclaw.ai/sandbox

[glacial ether]

Nice, this narrows it down a lot.

Your host is fine, gog exists at /usr/local/bin/gog. The problem is just that personal is running fully sandboxed (mode: all), so the sandbox cannot see that host binary.

Also, with gog there’s a second gotcha right after the binary: its OAuth creds usually live under ~/.config/gogcli, and the sandbox usually won’t have those either.

My recommendation for this agent

If personal is your own trusted agent, turn sandboxing off just for that agent:

{
  agents: {
    list: [
      {
        id: "personal",

        sandbox: { mode: "off" }
      }
    ]
  }
}

Then apply it with:

openclaw sandbox recreate --agent personal

After that, try a fresh turn with the personal agent.

If you want to keep sandboxing on

That’s possible, but it’s more annoying:

• add gog inside the sandbox image or agents.list[].sandbox.docker.setupCommand
• also make gog auth available inside the sandbox somehow

So for gog, per-agent sandbox.mode: "off" is usually the pragmatic answer.

Docs:

• https://docs.openclaw.ai/gateway/sandboxing
• https://docs.openclaw.ai/cli/sandbox

Glad we caught it. If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

[burnt plover]

should I just create a tool that exposes gog?

[glacial ether]

I wouldn’t make a generic “run gog” tool just as a workaround.

That’s basically handing the model a Google-powered shell command surface, which is a lot broader than you probably want.

What I’d recommend instead:

1. Short term, simplest

   • keep personal unsandboxed, or
   • make a dedicated google/personal agent with sandbox.mode: "off"

2. If you want a real long-term integration

   • build a narrow plugin tool, not a generic gog argv wrapper
   • expose specific actions like:
     • gmail_search
     • calendar_list_events
     • drive_search
   • keep write actions like send/create/delete separate and confirmation-heavy

That gives you:

• structured params/results
• much less prompt-injection surface
• easier permission control
• better UX than shelling out through a skill

So: yes to a proper narrow tool, no to a raw gog passthrough.

If you want, I can sketch the cleanest design for a gog plugin tool set in OpenClaw.

Docs:

• https://docs.openclaw.ai/plugins/building-plugins
• https://docs.openclaw.ai/tools/skills

[burnt plover]

I think I'm getting close, trying with "sandbox": "off" for the personal agent, now how do I allow the main agent to delegate to the personal agent for email questions?

[glacial ether]

Yep, that’s the right direction.

For main -> personal delegation, the key config is on the main agent:

{
  agents: {
    list: [
      {
        id: "main",
        subagents: {
          allowAgents: ["personal"],
          requireAgentId: true,
        },
      },
      {

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

A couple important gotchas:

1. The allowlist belongs to the caller

   • so set subagents.allowAgents on main, not personal

2. If main is sandboxed, this will still be blocked

   • OpenClaw won’t let a sandboxed requester spawn an unsandboxed target
   • so if main is sandboxed and personal is not, delegation via sessions_spawn will be rejected