Agent Deploy

Deploy a new isolated OpenClaw agent with its own Telegram bot, workspace, and session storage. Use when user asks to create a new agent, add a new bot, or s...

Security Scan

The skill's files match its stated purpose (deploying an agent and Telegram account) but its runtime instructions/scripts perform secret-copying and pass sensitive tokens on the command line in ways the user may not expect.

Purpose & Capability

The name/description align with the included scripts: they create workspaces, update OpenClaw config via the openclaw CLI, add Telegram accounts, and migrate single-bot setups. One notable capability is merging API keys from global and the main agent into the new agent's auth-profiles.json — functionally coherent for convenience but potentially surprising because it copies credentials between agents.

Instruction Scope

SKILL.md instructs the agent to run provided scripts verbatim. The scripts read ~/.openclaw/openclaw.json and (if present) ~/.openclaw/agents/main/agent/auth-profiles.json, write a new per-agent auth-profiles.json, and call `openclaw config set` to modify running config. They also expect the user to supply botToken as a command-line argument, which may expose it in process listings. The instructions do not warn about token exposure or require user confirmation before copying API keys, giving the agent broad discretion to read and replicate credentials.

Install Mechanism

No install spec or external downloads are present; this is an instruction + script bundle with only local files (bash and python). Nothing is being fetched from external URLs during install.

Credentials

The skill requests no declared environment variables, but the scripts access configuration files and per-agent auth files in the user's home (~/.openclaw). They merge global and main-agent API keys into the new agent, which is coherent for the task but elevates access to stored credentials. Passing the bot token as a CLI argument can leak the token via process listings; the skill does not provide an alternative secure input method.

Persistence & Privilege

The skill does not request always:true and does not modify other skills' configs. It performs changes via the openclaw CLI and writes agent-specific files under ~/.openclaw; these are expected for a deploy tool. Autonomy (model invocation) is allowed by default but is not combined with an elevated 'always' presence.

What to consider before installing

This skill appears to do what it claims, but review and consider the following before installing or running: 1) The deploy scripts copy API keys from global config and the main agent into the new agent's auth-profiles file — confirm you want credentials duplicated. 2) The bot token is passed as a command-line argument (deploy.sh <agentId> <botToken>), which can expose the token in process listings; prefer a mechanism that avoids putting secrets on argv (e.g., read from stdin or an env var) or use a temporary token. 3) Inspect the scripts yourself (they are small and included) and verify the openclaw CLI on your system is the trusted implementation the script expects. 4) Ensure backups and file permissions (on ~/.openclaw and auth files) are acceptable; the scripts do write new auth-profiles.json under ~/.openclaw/agents/<agent>/agent/. 5) If you don't want API keys copied, run the steps manually (or modify the helper to skip merge-auth). 6) If you proceed, run the commands in a controlled environment or test instance first. These behaviors explain why I rated the skill 'suspicious' rather than 'benign' — the functionality is coherent but handles sensitive secrets in ways users should explicitly acknowledge.

Agent Deploy & Isolation Skill

WHEN TO USE THIS SKILL

Use this skill when the user says ANY of the following (or similar):

• "deploy a new agent"
• "add a new agent"
• "create a new agent"
• "set up a new bot"
• "bind a bot to a new agent"
• "add a telegram bot"
• "list agents" or "show agents"
• "remove agent" or "delete agent"

WHAT YOU NEED FROM THE USER

Before running any deploy script, you MUST collect these two values from the user:

Required	Example	How to get it
agentId	research	Ask: "What should I name this agent?" (lowercase, no spaces, no special chars)
botToken	123456:ABC-xyz	Ask: "What is the Telegram Bot Token?" (user gets this from @BotFather)

If the user provides both in their message, proceed immediately. If the user is missing one or both, ask for the missing value(s) before proceeding.

HOW TO EXECUTE

Action: DEPLOY a new agent

Run this exact command, replacing <agentId> and <botToken> with the user's values:

bash {baseDir}/scripts/deploy.sh <agentId> <botToken>

Example: If user says "deploy agent called research with token 123456:ABCdef":

bash {baseDir}/scripts/deploy.sh research 123456:ABCdef

After the script finishes:

• If output contains "SUCCESS": tell the user the agent is deployed.
• If output contains "CONFLICT": tell the user the agent already exists.
• If output contains "ERROR": tell the user what went wrong.
• If output contains "ROLLING BACK": tell the user the change was safely reverted.

DO NOT run systemctl restart unless the script output explicitly says to. The script handles hot-reload automatically for channels and bindings.

Action: LIST all agents

bash {baseDir}/scripts/list.sh

Show the output table to the user as-is.

Action: REMOVE an agent

Run this exact command, replacing <agentId>:

bash {baseDir}/scripts/remove.sh <agentId>

Example: If user says "remove the research agent":

bash {baseDir}/scripts/remove.sh research

STRICT RULES ??DO NOT VIOLATE

1. NEVER edit openclaw.json directly. Do not use write, edit, apply_patch, or any file editing tool on openclaw.json. The deploy script uses openclaw config set which is the only safe way.
2. NEVER skip the pre-flight check. Always run the full deploy.sh script. Do not try to run individual openclaw config set commands yourself.
3. NEVER change the agentId format. It must be lowercase letters, numbers, and hyphens only. No spaces, no uppercase, no special characters.
4. NEVER deploy without a valid bot token. The token must match the format: digits:alphanumeric (e.g., 123456789:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw).
5. NEVER modify the main agent. The remove.sh script refuses to remove the main agent. Do not try to work around this.

WHAT THE SCRIPT DOES AUTOMATICALLY

You do NOT need to do any of these manually. The script handles everything:

• Creates isolated workspace at ~/.openclaw/workspace-<agentId>/
• Adds agent to agents.list with safe defaults:
  • tools.deny: ["gateway"] (agent cannot modify core config)
  • sandbox.mode: "non-main" (non-main sessions are sandboxed)
  • sandbox.scope: "agent" (one container per agent)
  • sandbox.workspaceAccess: "none" (sandbox cannot access host workspace)
• Adds routing binding: <agentId> -> telegram:<agentId>
• Adds Telegram account with the bot token
• Validates with openclaw doctor
• Auto-rollbacks on any failure
• Merges API keys from BOTH global config (openclaw.json auth.profiles) AND main agent's auth-profiles.json
• Migrates from single-bot to multi-account mode if needed

TROUBLESHOOTING

If the user says the new bot is not responding after deploy:

1. First, check logs: journalctl --user -u openclaw-gateway --no-pager -n 20
2. Look for [telegram] [<agentId>] starting provider in logs
3. If NOT found, restart: systemctl --user restart openclaw-gateway
4. If still not working, run: bash {baseDir}/scripts/list.sh to verify config

ENVIRONMENT VARIABLES

These are optional. The scripts use sensible defaults:

Variable	Default	Description
OPENCLAW_CONFIG_PATH	~/.openclaw/openclaw.json	Custom config file path
OPENCLAW_BIN	openclaw	Custom openclaw CLI path