Openclaw Shopify Manager
ReviewAudited by ClawScan on May 18, 2026.
Overview
This Shopify connector is mostly purpose-aligned, but its default OAuth scopes are broad and its write-confirmation posture appears to rely on agent/user discipline rather than a runtime safeguard.
Before installing, narrow the Shopify scopes, start in read-only mode, protect the runtime .env file, test on a development store if possible, and require explicit confirmation before any product or content update.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If installed with defaults, the connector may receive permission to read order data and modify store products or content even if the user only intended a read-only or product-only setup.
The guided setup defaults to write permissions and order-read access. read_orders is broader than the main product/content workflows described, and write scopes affect live store data.
if (!scopes) return ['read_products', 'write_products', 'read_content', 'write_content', 'read_orders'];
Start with read-only scopes, remove read_orders unless the workflow needs it, and grant write_products/write_content only when specific write tasks are required.
A product or article update command could change live Shopify content if invoked after setup, unless the agent or user separately enforces confirmation.
The visible runtime gate blocks read-only mode and an allowlist mode, but does not appear to enforce an interactive confirmation for the documented default require-confirmation-for-mutations mode.
function ensureMutationAllowed(config, action) {
if (config.mode === 'read-only') {
throw new Error(`Mutation blocked: mode is read-only (${action})`);
}
if (config.mode === 'allow-approved-operations' && config.allowedMutations.length && !config.allowedMutations.includes(action)) {Use read-only mode until ready to write, require explicit user confirmation before every mutation, and consider adding a runtime --confirm/--yes check or dry-run preview for write commands.
If installed as a service, the connector may continue running after the setup session and after reboot.
The service template can keep the connector running persistently and across restarts. This is disclosed and useful for OAuth callbacks/webhooks, but users should notice the persistence.
ExecStart=/usr/bin/env node %h/oc/shopify-runtime/shopify-connector.mjs run-server Restart=always RestartSec=3 [Install] WantedBy=multi-user.target
Install the service only when needed, keep it bound to localhost behind a controlled proxy, monitor logs, and disable/remove the service when no longer required.
Running the helper executes local shell commands on the host.
The setup helper shells out to inspect local command availability, apparently for Tailscale checks. This is purpose-aligned local execution rather than hidden remote code execution.
execFileSync('bash', ['-lc', `command -v ${bin}`], { stdio: 'ignore' });Run the scripts from a trusted checkout, avoid running as root unless necessary, and review commands before using host/systemd setup.
Misconfigured public exposure could make the local connector reachable from the internet at the callback/webhook path.
The documented setup can expose the local callback/webhook server publicly through Tailscale. The connector includes HMAC validation in the visible code, so this is expected but security-sensitive.
tailscale serve --https=443 /shopify-manager http://127.0.0.1:8787 tailscale funnel --https=443 on
Verify the exact public URL, keep the local bind on 127.0.0.1, use Shopify HMAC validation, and disable Funnel/Serve when not needed.