OpenClaw Bug Report
ReviewAudited by ClawScan on May 3, 2026.
Overview
This is a coherent OpenClaw bug-report helper, but it should be used carefully because it runs a local diagnostics script, collects redacted logs/config metadata, and may post reviewed text to GitHub.
Use this skill only when you want to collect OpenClaw diagnostics for a bug report. Start with the default conservative collection, review every generated file, share only selected redacted excerpts, and approve GitHub posting only after reading the final text. The visible artifacts do not justify wallet credentials or raw tokens, so do not provide them if asked.
Findings (4)
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.
Running the skill can execute local diagnostic commands and create files on the user's machine.
The skill instructs the agent/user to execute a bundled shell script. This is expected for diagnostics, but it is still local code execution and should be reviewed.
bash /path/to/file-bug-report/scripts/collect-openclaw-diagnostics.sh --output ./openclaw-diagnostics
Run the script only when you intended to collect diagnostics, keep the default conservative options first, and inspect the generated bundle before sharing anything.
Private paths, plugin names, auth profile names, errors, prompts, or log excerpts could be included in local diagnostic files if not reviewed.
The diagnostics bundle may contain local config, log, git, and runtime context. The artifact includes good safeguards, but users still need to review stored diagnostic context before reuse or publication.
Default output is intentionally conservative: it records config metadata rather than raw config content... Use `--include-private-config`, `--include-tmp-logs`, or `--include-git-details` only after explaining the risk and getting explicit user approval. Inspect every generated file before sharing.
Do not upload the full diagnostics directory. Share only selected, reviewed, redacted excerpts, and avoid the private-config/tmp-log/git-detail flags unless necessary.
A GitHub issue or comment could be posted under the user's account, and the report could reveal which provider/auth profile or workspace type was involved.
The workflow may include account/profile details and can create public GitHub content after user approval. This is purpose-aligned but uses the user's delegated identity if posting is allowed.
Which model, provider, auth profile, workspace, and entrypoint were selected? ... User approves posting? ... Post issue or comment
Review the final issue/comment, selected GitHub account, target repository, and all environment/profile details before approving any post.
The registry signals could confuse users about whether sensitive credentials are needed.
The declared credential contract says no primary credential, while capability signals mention wallet/OAuth/sensitive credentials. The visible files do not justify wallet access, so this appears to be a metadata or signal mismatch rather than evidence of credential use.
Primary credential: none ... Capability signals: crypto; requires-wallet; requires-oauth-token; requires-sensitive-credentials
Do not provide wallet credentials, raw tokens, or unrelated secrets to this skill. If runtime prompts request them, stop and verify with the publisher.