multi-question

[robust fractal]

We’re running Azath House on OpenClaw v2026.4.23 and planning a controlled intake/upgrade to latest v2026.5.12. We’re building a Workflow OS: workflow-ts sidecar starts long-running human-gated engineering/
research workflows, dispatches OpenClaw agents into repo/worktree contexts, and eventually needs safe containerized execution.

Current questions where upstream guidance would materially affect our architecture:

1. Per-dispatch container/worktree binds:
   Can OpenClaw currently support setting sandbox/container mounts per spawned agent dispatch, e.g. mount a sidecar-created Git worktree as the agent’s only writable workspace? If yes, what is the canonical config/
   tool/API shape in 2026.5.12? If no, what is the recommended pattern until this exists?

2. Agent session idempotency:
   Does OpenClaw have, or plan, an idempotency key / resume key for agent dispatches so a workflow retry does not accidentally start duplicate agent work? Current workaround is storing dispatch results in workflow-ts
   and skipping on resume.

3. Per-agent connector/tool permissions:
   We want persona-scoped permissions like “Duiker can call only selected send-broker Quantified Self journal operations, not all send-broker connectors.” Is connector/operation-level allowlisting per agent supported
   today? If yes, what config schema is canonical? If not, should we implement this outside OpenClaw at the connector/gateway layer?

4. Plugin install/config mutation:
   We hit stale/half-plugin-install failure modes around immutable openclaw.json. We now use a guarded install path: unlock, ensure openclaw owns and can write config, run openclaw plugins install, then re-lock via
   EXIT trap. Does 2026.5.12 change the canonical plugin install/config mutation path? Any new built-in support for preserving dependencies/metadata or safer semantic config mutation?

5. Upgrade risk from 2026.4.23 -> 2026.5.12:
   Which release notes between 2026.4.23 and 2026.5.12 should we treat as high-impact for a multi-agent Workflow OS using Discord, custom plugins, gateway tools, workflow-trigger/workflow-step plugins, and eventually
   Dockerized worktree execution?

Desired output:

• Concrete answers where known.
• “Use this config/API” snippets if applicable.
• Warnings for anything we should not rely on.
• Recommended upgrade/preflight sequence for G10 gateway + Mac Mini node + custom plugins.

[remote jackal]

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

[hard silo]

I checked the 5.12 docs/source/changelog. Short version: 5.12 is a meaningful improvement for your Workflow OS shape, but it does not yet give you a first-class “spawn this native subagent with these one-off mounts/idempotency/connector-op grants” API.

1. Per-dispatch worktree/container binds
   Supported today: per-agent workspace + sandbox config, including Docker binds. Canonical shape is config, not dispatch params:

{
  agents: {
    list: [{
      id: "duiker",
      workspace: "/srv/azath/workspaces/duiker",
      sandbox: {
        mode: "all",
        scope: "agent",
        workspaceAccess: "rw",
        docker: { binds: ["/srv/azath/worktrees/task-123:/workspace:rw"] }
      },

      tools: { allow: ["read", "write", "edit", "apply_patch", "exec", "process"] }
    }]
  }
}

Docs: https://docs.openclaw.ai/gateway/sandboxing and https://docs.openclaw.ai/tools/multi-agent-sandbox-tools

But: I would not rely on per-dispatch native sessions_spawn.cwd for this. In 5.12 source, cwd is schema-visible, but native runtime:"subagent" does not carry it into spawnSubagentDirect; resumeSessionId/cwd behavior is effectively ACP/harness-oriented. Native subagents inherit/resolve workspace through agent/session metadata and config.

Recommended pattern until first-class dispatch mounts exist:

• Make workflow-ts allocate a stable worktree path per workflow attempt.
• Either maintain a small pool of configured agent ids/personas with fixed sandbox roots, or temporarily generate/update an agent config entry for that workflow lane, then restart/reload as required.
• If you need true per-job isolation now, use an external container/harness layer and dispatch OpenClaw/ACP into that cwd, or expose a workflow-owned tool that operates only inside the workflow’s worktree.
• Treat Docker binds as privileged: they bypass sandbox FS controls except for OpenClaw’s bind validation, so keep mounts narrow and prefer :ro unless the job really writes.

2. Agent dispatch idempotency

No first-class native subagent idempotencyKey/resume key found for sessions_spawn. Native subagent completions and internal delivery use idempotency internally, but callers don’t get a durable “same key = same child run” contract.

ACP has resumeSessionId, but docs explicitly say it’s ACP-only and ignored for native subagents. It resumes upstream ACP conversation history; it is not a generic OpenClaw workflow idempotency key.

So your current workaround is the right architectural choice: workflow-ts should persist {workflowRunId, stepId, OpenClaw childSessionKey/runId/taskName} and skip/steer/resume based on that on retry.

3. Per-agent connector/tool permissions
   Supported today: tool-level allow/deny per agent, provider, sandbox, and subagent. Example:

{
  agents: {
    list: [{
      id: "duiker",
      tools: {
        allow: ["read", "send_broker_quantified_self_journal"],
        deny: ["exec", "process", "browser", "gateway"]
      }
    }]
  }
}

Filtering order includes global policy, provider policy, agents.list[].tools.allow/deny, sandbox policy, and subagent policy. 5.12 also added inheritance of tool restrictions for delegated sessions, plus per-sender tool policies.

But OpenClaw’s built-in policy boundary is tool identity, not arbitrary connector sub-operation semantics inside one broad tool. If send-broker exposes one tool with many operations, OpenClaw cannot safely allow only “QS journal write” unless those operations are separate tool names or the connector enforces it. For Duiker, I’d implement operation allowlisting in the connector/gateway layer, and ideally expose narrow tools per capability.

4. Plugin install/config mutation
   Yes, 5.12 improves this area. Important changes:

• Plugin install/update/enable/disable/uninstall can write through a single-file $include backing plugins, leaving root openclaw.json untouched.
• Root includes, include arrays, and includes with sibling overrides fail closed.
• Install metadata is now machine-managed in plugins/installs.json under state, not user config.
• Update/doctor now preserve plugin install records better.
• Semantic config mutations are centrally serialized/retried, reducing concurrent clobber/half-write risk.
• Managed plugin peer deps are refreshed/preserved/pruned more safely.

Canonical path: prefer openclaw plugins update <id-or-spec> for already tracked plugins; use plugins install --force only when intentionally overwriting. For immutable config setups, the cleanest pattern is to move plugins to a writable single-file include and keep the root locked. Docs: https://docs.openclaw.ai/cli/plugins

5. High-impact upgrade notes for your case
   Treat these as preflight focus areas:

• Plugin architecture churn: 2026.5.2 is explicitly called out in testing docs as a plugin-architecture churn boundary; 2026.4.23 is a pinned plugin compatibility boundary.
• Externalized runtime deps: Slack, OpenShell sandbox, Anthropic Vertex, Bedrock, and WhatsApp-related pieces moved further out of core. Verify installed plugins and dependencyStatus, not just config.

• Gateway protocol: 5.12 requires v4 clients and changed streaming frames for SDK clients. Any custom workflow-ts Gateway client should be tested against 5.12.
• Security hardening: more scope checks, node provenance checks, browser/sandbox auth checks, truncated exec approval rejection, hook CLI authority limits. Good, but custom plugins/tools may surface missing-scope bugs.
• Sandbox/Docker: safer bind validation, Windows credential-root blocking, Docker setup path leak fixes, OAuth secret-key mount fixes. Re-test containerized workflows.
• Agents/subagents: subagent model precedence changed (agents.defaults.subagents.model now applies before target agent primary model), tool restrictions are inherited by delegated sessions, same-process completion handoff changed, and session/status classification changed for ACP children.
• Discord: main text path mostly looks like fixes; voice behavior changed around realtime auth and allowed voice channels. If you use voice, test separately.

Recommended controlled preflight:

1. Snapshot G10 state/config/auth/plugin index/sessions: ~/.openclaw, openclaw.json, plugin dirs, custom plugin source, workflow-ts DB.
2. On staging, install 5.12 and run: openclaw doctor, openclaw plugins list --json, openclaw plugins doctor, openclaw agents list --bindings, openclaw gateway status --deep --require-rpc.
3. Upgrade/update custom plugins explicitly; run openclaw plugins inspect <id> --runtime --json for workflow-trigger, workflow-step, send-broker, and any Gateway-method plugins.
4. Test workflow-ts against 5.12 Gateway protocol with one non-destructive workflow: dispatch → human gate → retry/resume → subagent completion → plugin hook/session_end.
5. Test Mac Mini node pairing/scopes after upgrade; 5.12 hides pending node capability surfaces until approval and has stricter node provenance checks.
6. Test Docker sandbox with a disposable worktree and narrow bind; verify writes cannot escape and