Description

The CLI runner auto-detects image file path references inside the prompt text (including absolute paths like /path/to/image.png, ~/Pictures/..., and file://...) and loads them from disk without enforcing workspaceOnly. With the new Anthropic backend defaults imageArg: "@", the runner then prefixes the emitted paths with @, which Claude CLI interprets as “attach this local file as an image”.

This enables a prompt-injection style data exfiltration of any local image file readable by the OpenClaw process (e.g., screenshots, camera photos, exported diagrams containing secrets), because an untrusted prompt can include an image-looking absolute path and the host will read and attach it.

Key points:

• Input: untrusted prompt text (LLM/user-controlled) containing a path ending in an image extension.
• File read: loadPromptRefImages() → loadImageFromRef() loads from filesystem.
• Missing guard: loadPromptRefImages() is called without workspaceOnly: true, so absolute paths and ../ outside workspace are allowed (unless a sandbox is used elsewhere).
• Exfil sink: appendImagePathsToPrompt(..., prefix="@") when backend.imageArg === "@" causes Claude CLI to read and send the file contents.

Vulnerable code:

const resolvedImages = ... : await loadPromptRefImages({ prompt, workspaceDir: params.workspaceDir });
...
prompt = appendImagePathsToPrompt(prompt, imagePaths, params.backend.imageArg === "@" ? "@" : "");

Recommendation

Enforce a strict local-file policy for prompt-detected image references.

Minimum safe fix (recommended): default to workspaceOnly: true for CLI backends, unless explicitly opted out.

const resolvedImages =
  params.images && params.images.length > 0
    ? params.images
    : await loadPromptRefImages({
        prompt,
        workspaceDir: params.workspaceDir,
        workspaceOnly: true, // prevent absolute paths / traversal outside workspace
      });

Additionally:

• Reject absolute paths and file:// refs for CLI backends unless a sandbox/allowlist is configured.
• If backend.imagePathScope === "workspace", also enforce workspaceOnly: true to align “where images are written” with “what can be read”.
• Consider a separate config flag like allowPromptImagePaths: false by default, requiring explicit user opt-in for local-path image loading.

Description

OpenClaw’s Anthropic Claude CLI backend now passes --allowedTools mcp__openclaw__* by default.

This is risky because Claude Code’s --allowedTools is a coarse client-side tool allowlist. The wildcard enables every tool exposed by the openclaw MCP server namespace, including highly sensitive approval-management tools.

In src/mcp/channel-tools.ts, the OpenClaw MCP server registers tools such as permissions_respond, which calls through to bridge.respondToApproval() and ultimately to gateway approval resolution methods:

• permissions_respond can allow pending exec/plugin approval requests.
• If the model can invoke this tool, it may be able to approve its own exec/plugin requests, bypassing intended human approval gates.

Vulnerable change (enables the wildcard by default):

"--allowedTools",
"mcp__openclaw__*",

This is especially concerning because the wildcard is applied to both fresh and resumed sessions, so it persists across runs.

Recommendation

Avoid wildcard tool enablement; explicitly allow only the minimal set of MCP tools required.

Option A (preferred): do not set --allowedTools by default; instead, compute a precise list from OpenClaw’s effective tool policy and pass only those names.

Option B: explicitly deny sensitive approval/administrative tools from the MCP server namespace (or move them behind an owner-only gate enforced server-side).

For example, restrict to read-only conversation tools and exclude permissions_respond:

args: [
  ​// ...
  "--allowedTools",
  "mcp__openclaw__conversations_list,mcp__openclaw__conversation_get,mcp__openclaw__messages_read"
]

Additionally, enforce authorization server-side for approval resolution regardless of client allowlists (e.g., require an authenticated owner/admin identity for exec.approval.resolve / plugin.approval.resolve).

Description

isOpenClawRequestedYolo() infers OpenClaw's effective exec policy as YOLO when tools.exec.security / tools.exec.ask are unset, defaulting them to "full" and "off". This can incorrectly enable Claude CLI's noninteractive permission mode (--permission-mode bypassPermissions) even when OpenClaw is configured for sandboxed execution where the documented default security is deny.

Impact:

• If a user sets tools.exec.host: "sandbox" (or an agent override) but does not explicitly set tools.exec.security, OpenClaw's effective exec policy is expected to be safer (security=deny by default for sandbox).
• The current inference ignores host and assumes security=full, causing resolveClaudePermissionMode() to return bypassPermissions.
• normalizeClaudeBackendConfig() then appends --permission-mode bypassPermissions, potentially disabling Claude Code’s interactive permission checks unexpectedly.

Vulnerable code:

const security = exec?.security ?? "full";
const ask = exec?.ask ?? "off";
return security === "full" && ask === "off";

Recommendation

Derive the effective exec policy using the same logic as the runtime (including host-dependent defaults), or at minimum incorporate tools.exec.host when choosing defaults.

For example, compute defaults consistent with /src/agents/exec-defaults.ts (sandbox defaults to deny):

function isOpenClawRequestedYolo(ctx?: CliBackendNormalizeConfigContext): boolean {
  const agentExec = ctx?.agentId
    ? ctx.config?.agents?.list?.find((a) => a.id === ctx.agentId)?.tools?.exec
    : undefined;
  const exec = agentExec ?? ctx?.config?.tools?.exec;

  const host = exec?.host ?? "auto";
  const defaultSecurity = host === "sandbox" ? "deny" : "full";
  const security = exec?.security ?? defaultSecurity;
  const ask = exec?.ask ?? "off";

  return security === "full" && ask === "off";
}

Even better: pass in (or resolve) the already-computed effective exec policy (security/ask/host) from the core exec-policy resolver rather than re-deriving it here, to avoid future drift.

1. src/agents/cli-backends.test.ts, line 118-155 (link)

   Test duplicates production YOLO-detection logic

   isTestYoloConfig and normalizeTestPermissionMode in the test file re-implement the same defaulting logic as isOpenClawRequestedYolo / resolveClaudePermissionMode in production. If the default values for security or ask change in cli-shared.ts, this local copy will silently diverge and tests will stop catching the regression they were written to detect. Importing and delegating to the real helpers would keep the test behaviour in lock-step with production.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/agents/cli-backends.test.ts
   Line: 118-155
   
   Comment:
   **Test duplicates production YOLO-detection logic**
   
   `isTestYoloConfig` and `normalizeTestPermissionMode` in the test file re-implement the same defaulting logic as `isOpenClawRequestedYolo` / `resolveClaudePermissionMode` in production. If the default values for `security` or `ask` change in `cli-shared.ts`, this local copy will silently diverge and tests will stop catching the regression they were written to detect. Importing and delegating to the real helpers would keep the test behaviour in lock-step with production.
   
   How can I resolve this? If you propose a fix, please make it concise.