fast-claude-code

• Outcome: Review
• Latest audit: Sep 12, 2026 · 2:10 AM UTC
• Version: 1.0.5

Overview

This skill appears intended to run Claude Code jobs in the background, but it grants broad unattended authority and changes project agent hooks in ways users should review carefully.

Install only in trusted, version-controlled projects after reviewing the scripts. Prefer plan mode, avoid webhook or ntfy callbacks for sensitive work unless you control the destination, and be aware that Team mode can overwrite Claude Stop hooks and that task content may be written to /tmp or forwarded in callbacks.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Tool Hijacking and Spoofing: Modifies or replaces tools so legitimate-looking calls execute attacker logic
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (6)

T09 · Insecure Skill Coding Practices

Error

• Location: modes/team.sh:321
• Finding: Arbitrary Local Script Execution Through Template Path Traversal<![CDATA[ ## Vulnerability Details **File Location**: `modes/team.sh:321-324` **Vulnerability Type**: Unvalidated path traversal leading to arbitrary local shell-script execution **Risk Level**: High ### Vulnerable Code ```bash # Get template-specific spawn prompt if [[ -f "$TEMPLATES_DIR/$TEMPLATE.sh" ]]; then SPAWN_PROMPT=$(bash "$TEMPLATES_DIR/$TEMPLATE.sh") else ``` ### Technical Analysis The value of `--template` is accepted without an allowlist or path validation. It is concatenated with the trusted templates directory and the `.sh` suffix, and the resulting file is executed using `bash`. An attacker-controlled value can contain `../` components and escape the intended `templates/` directory. The `-f` check only confirms that the resolved path is a regular file; it does not ensure that the canonical path remains inside the templates directory. Because the file is explicitly passed to `bash`, it does not need to have its executable bit set. It only needs to be readable by the account running the Skill. ### Attack Path 1. The attacker places or identifies a readable shell script outside the `templates/` directory, with a filename ending in `.sh`. 2. The attacker supplies a traversal value such as: ```text --template ../../attacker/payload ``` 3. The constructed path resolves to: ```text <skill-root>/templates/../../attacker/payload.sh ``` 4. The regular-file test succeeds. 5. `bash` executes the attacker-selected script. 6. The script runs with the operating-system privileges and environment of the Skill process. ### Impact Assessment Successful exploitation provides arbitrary command execution as the user running the Skill. This may allow reading or modifying that user's files, accessing inherited environment variables, altering project source code, invoking installed programs, or initiating network connections permitted to that account. The vulnerability does not independently provide root privileges, but its scope includ ...[truncated 55 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace dynamic path construction with an explicit identifier-to-file mapping: ```bash case "$TEMPLATE" in parallel-review) TEMPLATE_FILE="$TEMPLATES_DIR/parallel-review.sh" ;; competing-hypotheses) TEMPLATE_FILE="$TEMPLATES_DIR/competing-hypotheses.sh" ;; fullstack-feature) TEMPLATE_FILE="$TEMPLATES_DIR/fullstack-feature.sh" ;; architecture-decision) TEMPLATE_FILE="$TEMPLATES_DIR/architecture-decision.sh" ;; bottleneck-analysis) TEMPLATE_FILE="$TEMPLATES_DIR/bottleneck-analysis.sh" ;; inventory-classification) TEMPLATE_FILE="$TEMPLATES_DIR/inventory-classification.sh" ;; simple-dialog) TEMPLATE_FILE="$TEMPLATES_DIR/simple-dialog.sh" ;; *) echo "Error: unsupported template" exit 1 ;; esac ``` 2. Reject values containing `/`, `\`, `..`, control characters, or shell metacharacters. 3. Canonicalize the selected path and verify that it remains beneath the canonical templates directory. 4. Prefer storing templates as non-executable data files rather than shell scripts when they only emit prompt text. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: modes/single.sh:158
• Finding: Unrestricted Claude Code Execution Is Enabled by Default<![CDATA[ ## Vulnerability Details **File Location**: `modes/single.sh:13, 113-118, 158-165`; also present in `modes/interactive.sh:13, 164-185` and `modes/team.sh:26, 146-148, 397-423` **Vulnerability Type**: Default permission bypass and automatic acceptance of safety warnings **Risk Level**: High ### Vulnerable Code ```bash PERMISSION_MODE="auto" ``` ```bash if [[ "$PERMISSION_MODE" == "auto" ]]; then log_warn "⚠️ Auto mode uses --dangerously-skip-permissions" log_warn " Claude Code will run all tools without confirmation" log_warn " Only use in trusted environments with version-controlled code" fi ``` ```bash case "$PERMISSION_MODE" in plan) CLAUDE_CMD="claude -p --permission-mode plan" ;; auto) CLAUDE_CMD="claude -p --dangerously-skip-permissions" ;; ``` Team and interactive modes additionally send confirmation input automatically when recognized permission warnings appear: ```bash tmux -L "$TMUX_SERVER" send-keys -t "$SESSION" "y" sleep 0.5 tmux -L "$TMUX_SERVER" send-keys -t "$SESSION" Enter ``` ### Technical Analysis All execution modes default to `auto`, which is mapped to Claude Code's `--dangerously-skip-permissions` option. This disables normal confirmation controls for tool use. Interactive and Team modes also contain logic that automatically accepts displayed safety or trust prompts. This design grants broad command and filesystem capabilities even for tasks that only require analysis, review, or discussion. The risk is particularly significant when the target repository contains untrusted instructions, malicious configuration, tool hooks, or prompt-injection content that the agent may follow while operating without confirmation. Displaying a warning does not enforce informed consent because unrestricted execution remains the default and the task is launched immediately. ### Attack Path 1. A user or orchestrating agent invokes Single, Interactive, or Team mode without explicitly ...[truncated 990 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make `plan` the default: ```bash PERMISSION_MODE="plan" ``` 2. Require a separate, explicit flag for unrestricted operation, such as `--allow-unrestricted-tools`. 3. Require interactive confirmation before enabling unrestricted execution. 4. Do not automatically respond to safety, trust-folder, or permission-bypass prompts. 5. Refuse unrestricted mode in unattended operation unless a trusted policy explicitly authorizes it. 6. Document that repository contents are untrusted input and may contain prompt injection. 7. Consider limiting subprocess environment variables and running Claude Code in a sandbox or container with a restricted filesystem and network policy. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: modes/interactive.sh:316
• Finding: Predictable Shared Temporary State File Is Executed With source<![CDATA[ ## Vulnerability Details **File Location**: `modes/interactive.sh:316-324` **Vulnerability Type**: Unsafe temporary file handling leading to local shell-code execution **Risk Level**: High ### Vulnerable Code ```bash # Create session state file for tracking start time (used by lifecycle monitor and send-task.sh) SESSION_STATE_FILE="/tmp/${SESSION}.state" echo "SESSION_START=$(date +%s)" > "$SESSION_STATE_FILE" echo "SESSION_LABEL=\"$LABEL\"" >> "$SESSION_STATE_FILE" echo "SESSION_NAME=\"$SESSION\"" >> "$SESSION_STATE_FILE" ( while true; do # Read current SESSION_START from state file (may be updated by send-task.sh) if [[ -f "$SESSION_STATE_FILE" ]]; then source "$SESSION_STATE_FILE" ``` ### Technical Analysis The lifecycle monitor stores state at a predictable path under the shared `/tmp` directory and later interprets the entire file as shell code using `source`. The implementation does not: - Create the file atomically. - Use a private directory. - Enforce restrictive permissions. - Verify ownership. - Reject symbolic links. - Validate file type immediately before reading. - Parse only expected numeric or textual fields. Consequently, any local process able to replace or modify the state file can inject arbitrary shell syntax. The injected commands execute in the lifecycle monitor's shell with the privileges of the Skill user. The session name is derived from a caller-controlled label, making the path easier to predict. ### Attack Path 1. The attacker determines or predicts the interactive session label. 2. The attacker derives the state path: ```text /tmp/cc-<label>.state ``` 3. The attacker replaces, modifies, or pre-creates the path with content such as: ```bash SESSION_START=0 attacker_command ``` 4. The lifecycle monitor reaches: ```bash source "$SESSION_STATE_FILE" ``` 5. Bash interprets the attacker-controlled content as shell commands. 6. The injected command executes ...[truncated 578 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Never use `source` to read state data. 2. Create a private runtime directory: ```bash RUNTIME_DIR=$(mktemp -d "${TMPDIR:-/tmp}/fast-claude.XXXXXX") chmod 700 "$RUNTIME_DIR" SESSION_STATE_FILE="$RUNTIME_DIR/session.state" ``` 3. Store only plain values and parse them explicitly. 4. Validate `SESSION_START` as digits before arithmetic: ```bash [[ "$SESSION_START" =~ ^[0-9]+$ ]] || exit 1 ``` 5. Create files atomically with restrictive permissions and reject symbolic links. 6. Restrict session labels to a safe character set such as `[A-Za-z0-9_-]+`. 7. Remove private runtime directories on every normal and abnormal exit using a trap. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: modes/single.sh:181
• Finding: Callback Path Traversal Allows Execution of an Attacker-Selected Shell Script<![CDATA[ ## Vulnerability Details **File Location**: `modes/single.sh:181-198`; equivalent construction is used in `modes/interactive.sh`, `modes/send-task.sh`, and generated Team hooks **Vulnerability Type**: Unvalidated callback identifier used as an executable path **Risk Level**: High ### Vulnerable Code ```bash if grep -q "CC_CALLBACK_DONE" <<< "$OUTPUT"; then TASK_OUTPUT=$(echo "$OUTPUT" | sed -n '1,/CC_CALLBACK_DONE/p' | sed '$d') "$BASE_DIR/callbacks/$CALLBACK.sh" \ --status done \ --mode single \ --task "a single task" \ --message "$TASK" \ --output "$TASK_OUTPUT" \ --session-key "$SESSION_KEY" else "$BASE_DIR/callbacks/$CALLBACK.sh" \ --status error \ --mode single \ --task "a single task" \ --message "$TASK" \ --output "CC_CALLBACK_DONE marker not found. Original output:\n${OUTPUT}" \ --session-key "$SESSION_KEY" fi ``` ### Technical Analysis The documentation describes `openclaw`, `webhook`, and `ntfy` as supported callback types, but the code does not enforce this set. The caller-controlled `CALLBACK` value is inserted into an executable path: ```text <skill-root>/callbacks/<CALLBACK>.sh ``` Traversal components can escape the callbacks directory. Quoting prevents shell metacharacter expansion but does not prevent filesystem path traversal. The selected script is executed when completion or failure handling occurs. Unlike the template issue, the target script must be executable because it is invoked directly rather than passed to `bash`. ### Attack Path 1. The attacker places or identifies an executable shell script outside the callback directory whose filename ends in `.sh`. 2. The attacker invokes a mode with a callback value such as: ```text --callback ../../attacker/payload ``` 3. The Claude task finishes, emits the completion marker, or reaches the error callback branch. 4. The constructed callback path resolves outsi ...[truncated 587 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Resolve callback names through a fixed mapping: ```bash case "$CALLBACK" in openclaw) CALLBACK_SCRIPT="$BASE_DIR/callbacks/openclaw.sh" ;; webhook) CALLBACK_SCRIPT="$BASE_DIR/callbacks/webhook.sh" ;; ntfy) CALLBACK_SCRIPT="$BASE_DIR/callbacks/ntfy.sh" ;; *) echo "Error: unsupported callback" exit 1 ;; esac ``` 2. Perform validation before starting any background task. 3. Reject callback values containing path separators, traversal components, whitespace, or control characters. 4. Use the validated absolute path consistently in Single, Interactive, Send Task, and Team modes. 5. Avoid passing sensitive session data through command-line arguments where it may be visible in process listings; use protected standard input or a private file descriptor instead. ]]>

T07 · Tool Hijacking and Spoofing

Warning

• Location: modes/team.sh:271
• Finding: Team Mode Replaces Existing Claude Stop Hooks<![CDATA[ ## Vulnerability Details **File Location**: `modes/team.sh:271-300` **Vulnerability Type**: Destructive security-hook configuration replacement **Risk Level**: Medium ### Vulnerable Code ```bash # Create or update .claude/settings.json with hooks configuration (always run, not just on fresh install) HOOKS_CONFIG=$(cat <<'HOOKSJSON' { "Stop": [ { "matcher": "", "hooks": [ { "type": "command", "command": ".claude/hooks/on-stop.sh" } ] } ] } HOOKSJSON ) mkdir -p "$PROJECT_DIR/.claude" # Upsert Stop hook in settings.json if [ -f "$SETTINGS_FILE" ]; then # Settings file exists, merge Stop hook (replace entire Stop array) jq --argjson newHooks "$HOOKS_CONFIG" ' .hooks = (.hooks // {}) | .hooks.Stop = $newHooks.Stop ' "$SETTINGS_FILE" > "$SETTINGS_FILE.tmp" mv "$SETTINGS_FILE.tmp" "$SETTINGS_FILE" ``` ### Technical Analysis When `.claude/settings.json` already exists, Team mode replaces the entire `.hooks.Stop` array with its own hook configuration. It does not append a unique entry or preserve existing Stop hooks. The generated cleanup routine only removes references to `.claude/hooks/on-stop.sh`; it does not retain a backup of the original Stop array and therefore cannot restore hooks overwritten during installation. Existing hooks may perform security enforcement, auditing, cleanup, validation, or other project-specific behavior. Replacing them silently changes the behavior of a legitimate tool configuration. ### Attack Path 1. A project contains one or more existing Claude Stop hooks. 2. Team mode is invoked for that project. 3. The `jq` update assigns: ```jq .hooks.Stop = $newHooks.Stop ``` 4. Every existing Stop hook is removed from the active configuration. 5. Claude Code runs without those hooks. 6. Cleanup removes the Team hook but does not restore the previous configuration. ### Impact Assessment This issue can disable project-local contr ...[truncated 351 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Preserve existing Stop hooks and append only the Skill's uniquely identified entry. 2. Check for an exact existing callback entry before appending to prevent duplicates. 3. Back up the original settings file before modification. 4. Record the exact entry added by the Skill and remove only that entry during cleanup. 5. Use atomic writes and validate the generated JSON before replacing the original file. 6. Install cleanup traps so configuration restoration also occurs after errors or interrupted runs. 7. If replacing hooks is operationally unavoidable, require explicit user approval and restore the original array after execution. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: modes/team.sh:364
• Finding: Sensitive Task Content Is Written to a Shared Persistent Debug Log<![CDATA[ ## Vulnerability Details **File Location**: `modes/team.sh:364-369` **Vulnerability Type**: Plaintext sensitive-data exposure through unsafe debug logging **Risk Level**: Medium ### Vulnerable Code ```bash # DEBUG: Log start echo "[DEBUG] $(date): Team mode starting" >> /tmp/team-debug.log echo "[DEBUG] PROJECT_DIR=$PROJECT_DIR" >> /tmp/team-debug.log echo "[DEBUG] TEMPLATE=$TEMPLATE" >> /tmp/team-debug.log echo "[DEBUG] TASK=$TASK" >> /tmp/team-debug.log echo "[DEBUG] PERMISSION_MODE=$PERMISSION_MODE" >> /tmp/team-debug.log ``` ### Technical Analysis Team mode unconditionally appends the complete task text and project metadata to a fixed file under the shared `/tmp` directory. The file is not created with explicitly restrictive permissions and is not removed after execution. Task descriptions may contain source-code fragments, internal paths, incident details, credentials, tokens, customer information, or other confidential operational data. A fixed path also permits local pre-creation and symbolic-link attacks, subject to the host's filesystem protections and the Skill user's permissions. Because logging is unconditional, users cannot avoid this disclosure while using Team mode. ### Attack Path 1. A user launches Team mode with a sensitive task description. 2. The script appends the complete task to: ```text /tmp/team-debug.log ``` 3. The log remains after the Team task exits. 4. Another local process or user with permission to read the file obtains the task and project metadata. Where platform protections permit, an attacker may pre-create the path as a symbolic link, causing the Skill to append content to another file writable by the Skill account. ### Impact Assessment The vulnerability may disclose confidential prompts, repository locations, operational context, or secrets included in task text to other local users or processes. It also creates persistent data retention outside the project. The issue does not inherently tra ...[truncated 132 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove unconditional debug logging of task content. 2. Make debugging explicitly opt-in through a disabled-by-default environment variable or flag. 3. Never log complete prompts, credentials, tokens, or captured model output. 4. If local logging is required, create a private file atomically with mode `0600` in a user-owned runtime directory. 5. Redact sensitive values before writing diagnostic information. 6. Add retention limits and guaranteed cleanup. 7. Reject symbolic links and avoid fixed shared temporary paths. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration

Findings (47)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The declared description presents a broader 'Claude Code task completion callback runtime' that specifically says tasks run in background tmux sessions and completion is notified via System Event. The supplied code chunk is only a notification callback sender. It does not manage tmux sessions, run tasks, or implement mode-specific runtime behavior; it merely accepts a mode string and includes it in the message body. More importantly, the notification mechanism materially differs: instead of local System Event notification, it sends notifications to an ntfy server using the ntfy CLI or curl, which introduces undeclared outbound network communication. That is a meaningful description-to-behavior mismatch rather than a minor implementation detail.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 90% confidence
• Finding: The description presents a broader runtime that runs Claude Code tasks in background tmux sessions and notifies on completion via System Event. The supplied code does not run tasks, manage tmux, or emit system events. Instead, it only accepts callback arguments, constructs a summary message, and forwards it to an OpenClaw agent gateway (or echoes it). While this is loosely related to task completion callbacks, the primary behavior and notification mechanism materially differ from the declared description.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The description emphasizes a runtime for Claude Code tasks that completes in the background and notifies via System Event. The supplied code chunk is specifically a webhook callback implementation: it posts task metadata and output to an external URL using curl. That is a materially different notification mechanism than the declared System Event behavior, and it introduces an undeclared network capability by transmitting potentially sensitive task data externally. While callbacks are broadly related to task completion, this code’s concrete behavior is not accurately represented by the description.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence
• Finding: The description is directionally related but does not accurately represent this specific code chunk. The code does run a Claude Code task in a background tmux session and arrange completion notification via hooks/callbacks, which matches the core Team-mode concept. However, it materially does more than a generic callback runtime: it installs and modifies Claude hook/settings files in the target project, saves task state, starts and controls a tmux session, may bypass permissions automatically using --dangerously-skip-permissions and simulated prompt acceptance, logs to /tmp, and on completion recursively lists project files and sends that listing to the callback. Those are meaningful undeclared capabilities/resource accesses. Also, the declared description says the skill supports Single / Interactive / Team modes, while this code chunk implements only Team mode. Therefore this is a description/behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description describes an execution runtime for Claude Code tasks with asynchronous completion notification behavior. The supplied code does not implement any runtime behavior, callbacks, background execution, tmux integration, notification mechanism, or mode handling. It simply emits a fixed prompt/template for an architecture decision debate workflow. This is a materially different primary purpose, so the description does not accurately represent the code.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description describes an execution runtime for Claude Code tasks: running jobs in background tmux sessions, tracking completion, and notifying via system events, with support for multiple runtime modes. The supplied code does none of that. It is a simple shell script that emits a fixed prompt template for coordinating four domain analysts in a performance investigation. There is no logic for spawning tmux sessions, managing task modes, monitoring execution, handling callbacks, or sending notifications. The code’s primary purpose is materially different from the declared purpose, so this is a clear description-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description promises a runtime component for executing Claude Code tasks in background tmux sessions and notifying on completion. The provided code does none of that: it is a simple Bash script that uses a heredoc to output a predefined prompt template for a competing-hypotheses debugging exercise. There is no tmux interaction, no callback handling, no notification mechanism, no mode handling, and no task lifecycle management. This is a material description-behavior mismatch, not just an implementation detail difference.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a task execution runtime with background execution and completion notification features. The supplied code does not implement any runtime behavior: it does not launch tasks, manage tmux sessions, detect completion, emit system events, or support execution modes. Instead, it outputs a canned prompt template for coordinating a full-stack feature across three teammates. This is a materially different primary purpose, so the description does not accurately represent the code chunk.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description promises a runtime component with execution management features: multiple modes (Single/Interactive/Team), background execution in tmux, and automatic completion notification via System Event. The supplied code does none of that. It is a simple shell script that prints a fixed prompt template describing how to spawn three workers for parallel item processing and aggregate their results. There is no evidence of tmux usage, callback handling, notification logic, mode selection, or actual task execution/runtime management. The code's primary purpose is prompt generation for a specific team parallelization pattern, which is materially different from the declared runtime/notification functionality.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description is for an execution/runtime component that manages Claude Code tasks in background tmux sessions and sends completion notifications. The supplied code does none of that: it only emits a static prompt template for coordinating three specialized review agents and synthesizing their outputs. This is a materially different primary purpose and lacks the core advertised capabilities of task execution, mode support, and completion notification.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence
• Finding: The declared description emphasizes a runtime responsible for executing Claude Code tasks in background tmux sessions and notifying on completion via system events. The supplied code does not implement any of those behaviors. It only emits a text template/instructions for a single-agent dialog scenario and asks the agent to print a completion marker. While the marker may relate to a larger callback system, this chunk itself is not a callback runtime, does not manage execution, does not use tmux, and does not send notifications. That is a material mismatch in primary purpose and capabilities.

Context-Inappropriate Capability

High

• Confidence: 96% confidence
• Finding: The script sends task, message, and output content to an arbitrary URL supplied by argument or environment variable, creating a clear exfiltration channel for potentially sensitive prompts, results, credentials, or file contents. In an agent runtime context, task output often contains confidential data, so unrestricted external transmission is materially dangerous even if it is framed as a callback feature.

Anti-Refusal Statement

High

• Category: Anti-Refusal

Content

# This tells Claude to always output CC_CALLBACK_DONE after every task completion
PROTOCOL_INSTRUCTION="⚠️ COMPLETION PROTOCOL (STRICT REQUIREMENT):

From now on, whenever you complete ANY task, answer ANY question, or respond to ANY request, you MUST output exactly the following marker on its own line:

CC_CALLBACK_DONE

• Confidence: 60% confidence
• Finding: Skill instructs the agent to never refuse or to always comply. Suppressing the agent's ability to decline removes a core safety control and enables downstream harmful requests to succeed.

Agent Config Directory Access

High

• Category: Agent Snooping

Content

# 1. Delete on-stop.sh file
# 2. Clean up settings.json entries that reference on-stop.sh
HOOKS_DIR="$PROJECT_DIR/.claude/hooks"
SETTINGS_FILE="$PROJECT_DIR/.claude/settings.json"

# Remove on-stop.sh hook file
rm -f "$HOOKS_DIR/on-stop.sh"

• Confidence: 91% confidence
• Finding: The script directly accesses and edits the agent configuration area under .claude/settings.json inside the user-supplied project path. Agent config is security-sensitive because it can define hooks and behavior; touching it from a task runner increases the chance of disabling protections or interfering with other agent workflows.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

SETTINGS_FILE="$PROJECT_DIR/.claude/settings.json"

# Remove on-stop.sh hook file
rm -f "$HOOKS_DIR/on-stop.sh"
log_info "Removed team hook file (on-stop.sh)"

# Clean up settings.json - remove any hook entries that reference on-stop.sh

• Confidence: 95% confidence
• Finding: The rm -f operation deletes a hook file inside a user-selected project path with no confirmation, backup, or validation that the deletion is necessary. Even though the target path is not shell-injected, it is still destructive behavior against project automation/security artifacts and can remove legitimate protections or workflow logic.

Context-Inappropriate Capability

High

• Confidence: 97% confidence
• Finding: The script supports an auto mode that launches Claude with '--dangerously-skip-permissions', which disables an important safety boundary for agent actions. In the context of a background tmux-runner that accepts arbitrary task text and project paths, this materially increases the chance of unintended or destructive operations without interactive review.

Agent Config Directory Access

High

• Category: Agent Snooping

Content

mkdir -p "$HOOKS_DIR"

# Settings file path (used regardless of whether hooks are already installed)
SETTINGS_FILE="$PROJECT_DIR/.claude/settings.json"

# Create unique session name for this team run
SESSION="cc-team-$(date +%s)"

• Confidence: 90% confidence
• Finding: Skill reads from agent configuration directories (.claude/, .codex/, .gemini/). These directories may contain API keys, personal settings, and other credentials that the skill has no legitimate need to access.

Agent Config Directory Access

High

• Category: Agent Snooping

Content

# Read original task from file (saved by team.sh)
if [[ -f ".claude/team-task.txt" ]]; then
    ORIGINAL_TASK=\$(cat ".claude/team-task.txt")
else
    ORIGINAL_TASK="\$CWD"
fi

• Confidence: 85% confidence
• Finding: Skill reads from agent configuration directories (.claude/, .codex/, .gemini/). These directories may contain API keys, personal settings, and other credentials that the skill has no legitimate need to access.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

--session-key "$SESSION_KEY"
# Cleanup: Remove team hooks after callback completes
# 1. Delete on-stop.sh hook file
rm -f ".claude/hooks/on-stop.sh"

# 2. Clean up settings.json - remove on-stop.sh references
if [ -f ".claude/settings.json" ] && command -v jq &> /dev/null; then

• Confidence: 95% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

fi

# 3. Remove team task file
rm -f ".claude/team-task.txt"
EOF

chmod +x "$HOOKS_DIR/on-stop.sh"

• Confidence: 95% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 88% confidence
• Finding: The skill clearly instructs users to invoke shell scripts and depends on shell-capable binaries like bash, claude, and tmux, yet it declares no explicit tool scope or allowed-tools policy. That gap weakens reviewability and containment because consumers cannot tell, from the manifest, what execution powers the skill expects or limits itself to.

Ssd 3

Medium

• Confidence: 94% confidence
• Finding: The callback template explicitly embeds the full original user request and full execution output into the notification message. In a background runtime that may process sensitive code, credentials, internal paths, or proprietary data, this creates a built-in semantic exfiltration path to whatever callback sink receives the message.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: This callback sends task metadata and potentially the last 1000 characters of command output to an ntfy server without any built-in consent, redaction, or destination validation. Because this skill runs background Claude Code tasks and notifies on completion, the transmitted output may contain sensitive prompts, file contents, secrets, or internal paths, making silent exfiltration a real risk even if the feature is intended for convenience.

External Transmission

Medium

• Category: Data Exfiltration

Content

if command -v ntfy &> /dev/null; then
    ntfy send -t "$TITLE" "$BODY" "$NTFY_SERVER"
else
    # Fallback to curl
    curl -s -X POST "$NTFY_SERVER" \
        -H "Title: $TITLE" \
        -d "$BODY"

• Confidence: 91% confidence
• Finding: The script performs an external HTTP POST to a user-controlled or environment-derived ntfy server using curl, carrying the assembled notification body. In this skill's context, that body can include task names, messages, and truncated output from background jobs, so the network transmission creates a concrete data-leak channel rather than a purely theoretical concern.

Ssd 3

Medium

• Confidence: 97% confidence
• Finding: The callback is intentionally constructed to include the original user request and the full execution output in a forwarded message to another agent/service. This creates a clear data exfiltration path for potentially sensitive prompts, file contents, command results, credentials, or internal state, especially because the skill description indicates tasks run in the background and notify automatically.

Static analysis

No suspicious patterns detected.