Claude Code Wingman
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: claude-code-wingman Version: 0.3.0 The skill is classified as suspicious due to multiple high-risk behaviors. The `SKILL.md` contains strong prompt injection instructions, explicitly telling the AI agent to "IMMEDIATELY run" shell commands (`handle-approval.sh`, `session-status.sh`) based on user input patterns, bypassing normal agent reasoning. The `auto-approver.sh` and `interactive-approver.sh` scripts automatically bypass Claude Code's internal security prompts (e.g., "Do you trust this folder?", "Do you want to proceed?"), significantly reducing the security posture of the Claude Code environment. Additionally, `lib/send-notification.sh` uses `curl` to send data to a configurable webhook, which, while defaulting to a local endpoint, could be overridden to an external malicious URL via environment variables (`CLAWDBOT_WEBHOOK_URL`), presenting a potential data exfiltration vector.
Findings (0)
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.
Claude Code may be allowed to run commands or modify project files without you seeing and approving each action.
The auto-approver automatically answers Claude Code permission prompts with an allow-for-session/project selection, which can authorize file edits, shell commands, or other tool actions without per-action user review.
elif echo "$OUTPUT" | grep -q "Do you want"; then ... # Option 2 is typically "Yes, and allow for session/project" ... tmux send-keys -t "$SESSION_NAME" Down Enter
Keep interactive approval as the default, avoid using --auto or 'always' except in tightly trusted projects, show the full requested command/file change before approval, and consider disabling automatic trust/tool approvals.
A local process could potentially spoof an approval or force an 'always approve' response for a Claude Code session.
Approval decisions are passed through predictable files under /tmp without explicit private-directory permissions, ownership checks, or a nonce. Code running as the same user, including untrusted project code, could potentially read pending prompts or write an approval response.
APPROVAL_DIR="/tmp/claude-approvals" ... RESPONSE_FILE="$APPROVAL_DIR/${SESSION_NAME}.response" ... RESPONSE=$(cat "$RESPONSE_FILE") ... always|2) ... tmux send-keys -t "$SESSION_NAME" Down EnterUse a per-user private runtime directory with 0700 permissions, chmod approval files to 0600, validate file ownership, and include an unpredictable token/nonce before acting on a response.
Installing/running the monitor gives the skill access to local Clawdbot notification authority, even though this credential use is not clearly declared in the registry metadata.
The notification helper reads the local Clawdbot config to obtain a webhook token and phone number, then uses that delegated authority to send WhatsApp messages. The registry metadata declares no required env vars, config paths, or primary credential.
CLAWDBOT_CONFIG="${CLAWDBOT_CONFIG:-$HOME/.clawdbot/clawdbot.json}" ... WEBHOOK_TOKEN=$(jq -r '.hooks.token // empty' "$CLAWDBOT_CONFIG" ... ) ... -H "Authorization: Bearer $WEBHOOK_TOKEN"Declare the Clawdbot config path and webhook token requirement, document exactly what is sent, and use a minimally scoped token dedicated to notifications if possible.
The monitor can continue running in the background, watching sessions and sending reminders after the initial task is started.
The package includes a long-running daemon that continuously monitors tmux sessions and sends approval notifications. This is aligned with the stated purpose, but users should know it persists until stopped.
# master-monitor.sh - Master daemon that monitors all Claude Code sessions ... while true; do ... sleep "$POLL_INTERVAL" ... done
Provide clear start/stop commands, restrict monitoring to Wingman-created sessions, and stop the daemon when remote approval monitoring is no longer needed.
You may run code that differs from the reviewed registry artifact if the remote repository changes.
The manual installation path pulls executable shell scripts from a mutable GitHub repository without a pinned commit or checksum. That is common for developer tools, but it is a provenance gap.
git clone https://github.com/yossiovadia/claude-code-orchestrator.git ... chmod +x *.sh lib/*.sh
Install from a pinned release or commit, review the scripts before chmod/execution, and keep the registry metadata aligned with required binaries such as jq/curl.