Oc

• Outcome: Review
• Latest audit: Sep 10, 2026 · 11:21 AM UTC
• Version: 1.1.0

Overview

This is a coherent OpenClaw troubleshooting skill, but it includes unsafe setup and repair paths that can expose credentials, weaken host security, or install mutable software.

Review this skill before installing. Use diagnostic/read-only commands first, avoid the setup wizard until credential storage and gateway defaults are fixed, do not follow Docker socket chmod guidance, and require explicit approval for package installs, Docker pulls, remote installer scripts, log deletion, or cache updates.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection

Findings (7)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/installation-errors.md:32
• Finding: Remote installation scripts are executed directly without integrity verification<![CDATA[ ## Vulnerability Details **File Location**: `references/installation-errors.md:32, 39, 105, 349, 367` **Vulnerability Type**: Remote payload retrieval followed by immediate shell execution **Risk Level**: High ### Vulnerable Code ```bash curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash ``` Additional instances include: ```bash curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - curl -fsSL https://get.pnpm.io/install.sh | sh - /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" ``` ### Technical Analysis The installation documentation streams externally hosted content directly into a shell. The downloaded response is not authenticated using a release signature or expected cryptographic digest and is not saved for inspection before execution. Although these commands appear in reference documentation rather than being invoked automatically by Python code, they are presented as operational remediation instructions. A user or agent following the instructions will execute the effective remote payload. The NodeSource examples are especially sensitive because the remote response is passed to a shell through `sudo`, giving the fetched payload root privileges. HTTPS protects the transport channel but does not protect against compromise of the upstream repository, hosting account, publishing workflow, or authorized content itself. ### Attack Path 1. An attacker compromises an upstream hosting account, repository, release process, or remote installation endpoint. 2. The attacker modifies the remotely served installation script. 3. A user follows the troubleshooting instructions. 4. `curl` retrieves the attacker-controlled response. 5. The shell interprets the response immediately, without integrity verification or review. 6. For the NodeSource command, the payload executes with root privileges. 7. The payload can modify system files, install services, steal credentia ...[truncated 382 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not pipe network responses directly into `bash` or `sh`. 2. Download a version-pinned installer to a temporary file first. 3. Obtain expected SHA-256 digests from an independently authenticated release channel. 4. Verify the digest or upstream release signature before execution. 5. Display the downloaded script and require explicit user approval. 6. Prefer distribution packages or package-manager repositories with signed metadata. 7. Separate privileged operations from unprivileged installation steps. 8. Pin installer versions instead of using mutable paths such as `HEAD`. 9. Document the exact files and system settings that the installer will modify. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/lib/setup_helpers.py:31
• Finding: Setup wizard persists provider API keys in plaintext configuration files and backups<![CDATA[ ## Vulnerability Details **File Location**: `scripts/lib/setup_helpers.py:31-52, 57-70`; `scripts/lib/utils.py:59-73` **Vulnerability Type**: Plaintext credential storage with no explicit restrictive file mode **Risk Level**: High ### Vulnerable Code ```python def generate_config(channels: list[str], ai_config: dict) -> dict: """Generate openclaw.json configuration.""" config = { "gateway": { "port": 18789, "bind": "0.0.0.0", "authMode": "token", "authToken": f"changeme-{hash(ai_config['api_key']) % 100000000:08d}" }, "agent": { "model": ai_config["model"], "provider": ai_config["provider"], "workspace": str(Path.home() / "openclaw-workspace"), "sandboxMode": "relaxed" }, "channels": {}, "skills": {}, "plugins": [] } config["agent"][f"{ai_config['provider']}_api_key"] = ai_config["api_key"] ``` The resulting configuration and backup are written as follows: ```python def save_config_with_backup(config: dict) -> bool: """Save config with backup of existing.""" if CONFIG_FILE.exists(): backup_file = CONFIG_FILE.with_suffix(".json.backup") try: import shutil shutil.copy2(CONFIG_FILE, backup_file) except Exception: pass return save_json(CONFIG_FILE, config) ``` ```python def save_json(path: Path, data: dict) -> bool: try: path.parent.mkdir(parents=True, exist_ok=True) with open(path, 'w', encoding='utf-8') as f: json.dump(data, f, indent=2) return True ``` ### Technical Analysis The setup wizard masks the API key while it is entered, but terminal masking does not protect the key after collection. `generate_config()` inserts the complete provider API key directly into the ordinary `openclaw.json` configuration object. The generic `save_json()` function creates the file usin ...[truncated 1400 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Store provider secrets in an operating-system credential manager or a dedicated OpenClaw secret store. 2. Persist only a secret reference in `openclaw.json`. 3. If file storage is unavoidable, create the file atomically with mode `0600` and ensure `~/.openclaw` is mode `0700`. 4. Verify and correct permissions after every write. 5. Apply the same restrictive permissions to backup files. 6. Avoid backing up secret-bearing files by default, or encrypt backups with an independently managed key. 7. Redact API keys from diagnostics, exceptions, logs, and generated reports. 8. Warn users explicitly that a secret will be persisted and provide a non-persistent alternative. 9. Add automated tests verifying that configuration and backup files are not group- or world-readable. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/lib/setup_helpers.py:31
• Finding: Public gateway configuration uses a weak token derived from the provider API key<![CDATA[ ## Vulnerability Details **File Location**: `scripts/lib/setup_helpers.py:31-43`; `scripts/lib/config_security_checks.py:23-31` **Vulnerability Type**: Predictable authentication token and unsafe network exposure **Risk Level**: High ### Vulnerable Code ```python def generate_config(channels: list[str], ai_config: dict) -> dict: """Generate openclaw.json configuration.""" config = { "gateway": { "port": 18789, "bind": "0.0.0.0", "authMode": "token", "authToken": f"changeme-{hash(ai_config['api_key']) % 100000000:08d}" }, ``` The corresponding security check only detects one exact token: ```python auth_token = gateway.get("authToken") if auth_token == "changeme": issues.append(ConfigIssue( severity="error", path="gateway.authToken", message="Using default auth token 'changeme'", fix_hint="Generate a secure random token for production use" )) ``` ### Technical Analysis The wizard binds the gateway to `0.0.0.0`, exposing it on every available network interface. It then generates an authentication token from Python's non-cryptographic `hash()` function and truncates the result to 100,000,000 possibilities. This provides at most approximately 27 bits of token space and does not constitute a cryptographically secure token-generation mechanism. The token also unnecessarily derives authentication material from the provider API key instead of using independent randomness. The security analyzer does not recognize generated values beginning with `changeme-` as weak because it only rejects the exact string `changeme`. ### Attack Path 1. A user runs the setup wizard with its default configuration. 2. The gateway is bound to every network interface. 3. The generated gateway token has only eight decimal digits following a known prefix. 4. A network attacker locates port 18789 through local discovery or scanning. 5. The attacker repeatedly tests ca ...[truncated 766 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Bind the gateway to `127.0.0.1` or `::1` by default. 2. Require an explicit, informed opt-in before listening on non-loopback interfaces. 3. Generate an independent token with a cryptographically secure generator, such as: ```python import secrets auth_token = secrets.token_urlsafe(32) ``` 4. Do not derive the gateway token from the provider API key. 5. Add rate limiting, authentication-failure backoff, and temporary lockout controls. 6. Expand security validation to reject known prefixes, short tokens, low-entropy formats, and public binds without compensating controls. 7. Require TLS or a trusted reverse proxy for remotely reachable deployments. 8. Rotate gateway tokens generated by affected versions. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/sandbox-errors.md:45
• Finding: Documentation recommends making the Docker control socket world-writable<![CDATA[ ## Vulnerability Details **File Location**: `references/sandbox-errors.md:45-49` **Vulnerability Type**: Local privilege escalation through unrestricted Docker daemon access **Risk Level**: Critical ### Vulnerable Code ```bash sudo usermod -aG docker $USER sudo chmod 666 /var/run/docker.sock ``` ### Technical Analysis The Docker daemon typically runs with root privileges. A process that can control its Unix socket can normally create privileged containers, mount arbitrary host paths, access host devices, and alter host files. Setting `/var/run/docker.sock` to mode `0666` grants read and write access to every local user and process. This is not a narrowly scoped fix for sandbox diagnostics; it removes an important access-control boundary. Adding a user to the `docker` group is also effectively root-equivalent on conventional Docker installations and must not be described as a routine, low-risk permissions fix. ### Attack Path 1. An administrator follows the sandbox troubleshooting instructions. 2. `/var/run/docker.sock` becomes writable by all local users. 3. An unprivileged local attacker connects to the Docker API. 4. The attacker creates a privileged container or mounts the host root filesystem into a container. 5. The attacker modifies host files, reads root-only data, or places a setuid binary or service on the host. 6. The attacker obtains effective root control outside the container. ### Impact Assessment Exploitation can result in complete host compromise, including root-level file access, credential theft, arbitrary process execution, container takeover, and persistent system modification. The impact is system-wide and affects all users and services on the host, not only OpenClaw. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the `chmod 666 /var/run/docker.sock` recommendation entirely. 2. Prefer rootless Docker where supported. 3. If group-based access is required, explain clearly that Docker group membership is root-equivalent. 4. Add only explicitly authorized administrative users to the Docker group. 5. Do not expose the Docker socket to containers unless strictly required. 6. Consider a constrained socket proxy that allows only necessary API operations. 7. Audit existing socket permissions and restore an appropriate owner and mode, commonly: ```bash sudo chown root:docker /var/run/docker.sock sudo chmod 660 /var/run/docker.sock ``` 8. Review Docker daemon logs for unauthorized container creation after correcting affected systems. ]]>

T06 · System Persistence

Warning

• Location: references/sandbox-errors.md:38
• Finding: Troubleshooting instructions enable Docker as a persistent boot service<![CDATA[ ## Vulnerability Details **File Location**: `references/sandbox-errors.md:38-39` **Vulnerability Type**: Unnecessary persistent service enablement **Risk Level**: Medium ### Vulnerable Code ```bash sudo systemctl start docker sudo systemctl enable docker ``` ### Technical Analysis Starting Docker may be necessary to diagnose or use Docker-backed sandbox functionality. Enabling the service is a separate operation that changes boot-time state and causes Docker to start after future reboots. This persistence exceeds the minimum privileges and duration required for a one-time diagnostic or repair operation. It also increases the duration for which the Docker API and container attack surface remain active. The instruction does not distinguish between temporary startup and persistent enablement and does not request separate approval for the persistent change. ### Attack Path 1. A user follows the sandbox troubleshooting instructions to resolve a temporary Docker error. 2. `systemctl enable docker` creates or activates boot-time service links. 3. Docker starts automatically on subsequent boots, even when OpenClaw sandboxing is not in use. 4. A vulnerable daemon, container, plugin, exposed API, or improperly protected socket remains available across sessions. 5. An attacker uses that continuing exposure to target the host. ### Impact Assessment The command does not itself install a covert backdoor, but it creates cross-session persistence for a privileged service. The resulting exposure includes Docker daemon vulnerabilities, insecure socket access, automatically restarted containers, and broader post-reboot attack surface. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Separate temporary startup from persistent service enablement. 2. Use `systemctl start docker` only when the user explicitly needs Docker immediately. 3. Present `systemctl enable docker` as an optional administrative decision with a clear persistence warning. 4. Require separate confirmation before making boot-time changes. 5. Provide a rollback command: ```bash sudo systemctl disable docker ``` 6. Recommend rootless or on-demand alternatives where practical. 7. Document the security implications of keeping a root-privileged container daemon active. ]]>

T08 · Insecure Dependencies

Error

• Location: references/channel-errors.md:310
• Finding: Signal CLI executable archive is installed without checksum or signature verification<![CDATA[ ## Vulnerability Details **File Location**: `references/channel-errors.md:310-312`; `references/auto-fix-capabilities.md:141-147` **Vulnerability Type**: Unverified third-party executable retrieval and system-wide linking **Risk Level**: High ### Vulnerable Code ```bash wget https://github.com/AsamK/signal-cli/releases/download/v0.11.11/signal-cli-0.11.11-Linux.tar.gz sudo ln -sf /opt/signal-cli-0.11.11/bin/signal-cli /usr/local/bin/ ``` ### Technical Analysis The instructions download an archive containing executable software from a third-party GitHub release and make the extracted executable available system-wide through `/usr/local/bin`. No expected SHA-256 digest, detached signature, signer identity, or verification procedure is supplied. A version-specific URL reduces accidental version drift but does not protect against compromise of the publisher account, repository, release assets, or installation path. Creating a system-wide symbolic link increases the trust placed in the downloaded binary because later invocations of `signal-cli` may resolve to that executable for all users. ### Attack Path 1. An attacker compromises the upstream repository, publisher account, release asset, or download path. 2. The attacker replaces the archive with a malicious executable payload. 3. A user follows the channel repair instructions and downloads the archive. 4. The archive is extracted under `/opt`. 5. A privileged symbolic link exposes the malicious executable through `/usr/local/bin/signal-cli`. 6. OpenClaw, an administrator, or another user invokes `signal-cli`. 7. The malicious binary executes with the invoking process's privileges and accesses Signal/OpenClaw data available to that process. ### Impact Assessment Successful exploitation can produce arbitrary code execution for users or services that invoke the installed binary. Potential access includes Signal registration information, message-processing data, OpenClaw configuration, user files, ...[truncated 158 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Publish the expected SHA-256 or stronger digest for the exact release archive. 2. Verify a detached release signature against a documented, trusted signing key. 3. Abort installation if any verification fails. 4. Prefer a signed operating-system package repository where available. 5. Extract into a version-specific directory owned by root and not writable by ordinary users. 6. Verify the target file before creating a system-wide link. 7. Avoid wildcard-based link targets. 8. Document upgrade and rollback procedures. 9. Re-verify the executable after upgrades. ]]>

T08 · Insecure Dependencies

Error

• Location: data/fix-recipes.json:227
• Finding: Automatic fixes install mutable global packages and Docker images<![CDATA[ ## Vulnerability Details **File Location**: `data/fix-recipes.json:227-307`; `SKILL.md:15-22`; `requirements.txt:1-4` **Vulnerability Type**: Unpinned and mutable supply-chain dependencies **Risk Level**: High ### Vulnerable Code ```json { "id": "fix-docker-pull", "title": "Pull OpenClaw Sandbox Image", "safe_auto": true, "description": "Download latest OpenClaw sandbox Docker image", "steps": [ { "type": "command", "command": "docker pull openclaw/sandbox:latest", "description": "Pull sandbox image from registry" } ] } ``` Other recipes marked safe for automatic execution include: ```json { "type": "command", "command": "npm install -g pnpm", "description": "Install pnpm via npm" } ``` ```json { "type": "command", "command": "npm install -g openclaw", "description": "Install openclaw globally via npm" } ``` The Skill installation command is also unpinned: ```yaml "command": "pip install click rich requests beautifulsoup4" ``` The requirements specify only lower bounds: ```text click>=8.1.0 rich>=13.0.0 requests>=2.31.0 beautifulsoup4>=4.12.0 ``` ### Technical Analysis The `latest` Docker tag is mutable and does not identify immutable image content. Global npm installation without an exact version similarly resolves to whatever the registry currently considers current. The Python installation command ignores even the lower bounds in `requirements.txt`, and no lockfile or hash verification is present. Package installers and container images can run or contain attacker-controlled code. Classifying these operations as `safe_auto` means a diagnostic invocation can cross into software installation without a dedicated supply-chain approval boundary. The issue does not establish that the named packages are presently malicious. The vulnerability is that future or compromised registry content can change the effective code after the Skill has been reviewed. ### Attack Path 1. An attacker compromise ...[truncated 1045 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace Docker tags with immutable image digests: ```text openclaw/sandbox@sha256:EXPECTED_DIGEST ``` 2. Pin exact npm and Python dependency versions. 3. Use lockfiles and hash-verified Python requirements. 4. Verify npm package provenance and signed registry metadata where supported. 5. Treat all package installation and image replacement operations as requiring explicit user approval. 6. Remove `safe_auto: true` from global installs, updates, and mutable image pulls. 7. Separate diagnostic fixes from software installation. 8. Display the package name, exact version or digest, source registry, and requested privilege scope before installation. 9. Maintain an allowlist of reviewed versions and provide deterministic rollback instructions. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Memory Poisoning: Persistent Context Injection, Context Window Stuffing, Memory Manipulation
• Rogue Agent: Self-Modification, Session Persistence
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (243)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 92% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The combination of undeclared update-checking and auto-detection/recommendation behavior with absent or overstated diagnostics indicates incomplete and misleading disclosure. Even if not overtly malicious, this weakens user consent and complicates security review because the real operational footprint differs from the advertised one.

Self-Modification

High

• Category: Rogue Agent

Content

python3 {baseDir}/scripts/enhanced-doctor.py --json
```

### Self-Updater
Keep references and caches current.
```bash
# Check what's outdated

• Confidence: 93% confidence
• Finding: A self-updater is a genuine self-modification capability: it can change the skill's local references or cached state after deployment. Even if intended for maintenance, self-modifying behavior increases supply-chain and integrity risk because future behavior may differ from what was originally reviewed.

Self-Modification

High

• Category: Rogue Agent

Content

Keep references and caches current.
```bash
# Check what's outdated
python3 {baseDir}/scripts/self-updater.py --check

# Update everything
python3 {baseDir}/scripts/self-updater.py --update

• Confidence: 95% confidence
• Finding: The '--update' command is a direct mutating action that can alter local data under control of the skill. In security-sensitive environments, any self-update path is dangerous unless tightly scoped and transparently controlled, because it can introduce unreviewed content or drift from the audited version.

Self-Modification

High

• Category: Rogue Agent

Content

python3 {baseDir}/scripts/self-updater.py --check

# Update everything
python3 {baseDir}/scripts/self-updater.py --update

# Update only skill cache
python3 {baseDir}/scripts/self-updater.py --update --skills-only

• Confidence: 95% confidence
• Finding: Updating the skill cache is still a self-modification pathway because it changes local reference material that may influence future outputs or recommendations. This is especially risky if the cache contents are sourced remotely or later trusted without verification.

Self-Modification

High

• Category: Rogue Agent

Content

python3 {baseDir}/scripts/self-updater.py --update

# Update only skill cache
python3 {baseDir}/scripts/self-updater.py --update --skills-only
```

### Setup Wizard

• Confidence: 92% confidence
• Finding: Documenting self-update-related commands without safeguards indicates a real integrity concern, even if the apparent goal is maintenance rather than exploitation. In this skill context, the danger is elevated because the same tool presents itself as a trusted 'doctor' utility, making users more likely to run mutating commands without scrutiny.

Credential Access

High

• Category: Privilege Escalation

Content

"title": "Missing Anthropic API Key",
      "description": "ANTHROPIC_API_KEY environment variable is not set",
      "causes": ["Environment variable not set", "API key not configured in openclaw.json", "Wrong environment file loaded"],
      "fix_steps": ["Set ANTHROPIC_API_KEY environment variable", "Add key to .env file", "Run: openclaw models auth setup-token --provider anthropic"],
      "fix_recipe_id": "fix-auth-env",
      "related_codes": ["INVALID_REQUEST"],
      "doc_url": "https://docs.openclaw.ai/providers/anthropic"

• Confidence: 88% confidence
• Finding: Advising users to add API keys to a `.env` file can increase credential exposure if the file is committed, copied, or left with weak permissions. In a diagnostic skill centered on fixing auth issues, normalizing local plaintext secret storage is risky unless accompanied by explicit safeguards and safer secret-management options.

Credential Access

High

• Category: Privilege Escalation

Content

"title": "Missing OpenAI API Key",
      "description": "OPENAI_API_KEY environment variable is not set",
      "causes": ["Environment variable not set", "API key not configured in openclaw.json", "Wrong environment file loaded"],
      "fix_steps": ["Set OPENAI_API_KEY environment variable", "Add key to .env file", "Run: openclaw models auth setup-token --provider openai"],
      "fix_recipe_id": "fix-auth-env",
      "related_codes": ["INVALID_REQUEST"],
      "doc_url": "https://docs.openclaw.ai/providers/openai"

• Confidence: 88% confidence
• Finding: This repeats the same risky pattern for OpenAI credentials by recommending storage in a `.env` file. Because this file is only documentation/config data, it is not credential theft by itself, but it still encourages a storage practice that can lead to accidental secret disclosure in real deployments.

Memory Manipulation

High

• Category: Memory Poisoning

Content

"title": "Context Window Exceeded",
      "description": "Request exceeds model's context window limit",
      "causes": ["Too many tokens in prompt", "Large conversation history", "Big file attachment", "Context accumulation"],
      "fix_steps": ["Reduce prompt length", "Clear conversation history", "Use model with larger context window", "Implement context pruning"],
      "fix_recipe_id": "fix-config-validate",
      "related_codes": ["PAYLOAD_TOO_LARGE"],
      "doc_url": "https://docs.openclaw.ai/models/context-limits"

• Confidence: 80% confidence
• Finding: Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.

Context-Inappropriate Capability

High

• Confidence: 95% confidence
• Finding: The skill can terminate arbitrary processes on a port using forceful kill commands, including 'kill -9', which can interrupt unrelated applications and cause data loss. For a diagnostic tool, this is unusually destructive because it converts troubleshooting into direct process control without strong safeguards.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: This cleanup recipe permanently deletes logs and prunes Docker resources without an explicit warning, making accidental destructive execution more likely. Loss of logs can impede debugging and incident response, while Docker pruning may remove resources other workloads depend on.

Credential Access

High

• Category: Privilege Escalation

Content

- Gateway rejects AI provider requests

**Common Causes:**
- Missing API key in .env file
- Incorrect API key value
- API key not activated with provider
- Typo in environment variable name

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

- Gateway rejects AI provider requests

**Common Causes:**
- Missing API key in .env file
- Incorrect API key value
- API key not activated with provider
- Typo in environment variable name

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

- Gateway rejects AI provider requests

**Common Causes:**
- Missing API key in .env file
- Incorrect API key value
- API key not activated with provider
- Typo in environment variable name

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Static analysis

Detected: suspicious.destructive_delete_command

Documentation contains a destructive delete command without an explicit confirmation gate.

Warn

• Code: suspicious.destructive_delete_command
• Location: references/installation-errors.md:517

Documentation contains a destructive delete command without an explicit confirmation gate.

Warn

• Code: suspicious.destructive_delete_command
• Location: references/troubleshooting-workflow.md:354