Security audit

.Autopilot

Security checks for vulnerabilities and agentic risk

Overview

This skill is a real Codex automation system, but it grants persistent, remote, and command-execution authority with several under-scoped safety controls.

Install only if you are comfortable running a persistent local automation service that can control Codex sessions, approve prompts, execute task-defined checks, and send project metadata to messaging services. Before use, remove hard-coded Discord fallbacks, require explicit Telegram chat authorization, lock down config-file permissions, and avoid accepting task YAML from untrusted repositories.

A.I.G

Vulnerability Patterns

Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions

Findings (5)

T09 · Insecure Skill Coding Practices

Error

Location: lib/done_checker.py:183
Finding: Repository-Controlled Arbitrary Shell Command Execution
Content: View full analysis
Remediation: View remediation

T05 · Unauthorized Access and Privilege Escalation

Error

Location: lib/telegram_bot.py:59
Finding: Telegram Command Authorization Fails Open When Chat ID Is Missing
Content: View full analysis
Remediation: View remediation

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: scripts/discord-notify.sh:16
Finding: Hard-Coded Discord Destinations Can Receive Development Metadata
Content: View full analysis
/dev/null <<'PY' || true import json import sys path = sys.argv[1] try: with open(path, "r", encoding="utf-8") as f: data = json.load(f) token = data.get("channels", {}).get("discord", {}).get("token", "") if isinstance(token, str): print(token.strip()) except Exception: pass PY ) ``` If normal configuration lookup fails, the fixed mapping is used: ```bash CHANNEL_ID="$(get_discord_channel_id_for_channel "$CHANNEL_NAME" 2>/dev/null || true)" if [[ -z "$CHANNEL_ID" ]]; then CHANNEL_ID="$(fallback_channel_id "$CHANNEL_NAME" 2>/dev/null || true)" ...[truncated 2429 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Warning

Location: install.sh:102
Finding: Telegram Bot Token Is Stored Without Enforced Restrictive Permissions
Content: View full analysis
/dev/null; then ok "Telegram configuration already exists (config.yaml)" else info "Configure Telegram notifications (optional; press Enter to skip)" read -rp " Bot Token: " tg_token read -rp " Chat ID: " tg_chat if [ -n "$tg_token" ] && [ -n "$tg_chat" ]; then cat > "$CONFIG_YAML" << EOF telegram: bot_token: "${tg_token}" chat_id: "${tg_chat}" EOF ok "Telegram configuration saved" else warn "Skipping Telegram configuration" fi fi ``` ### Technical Analysis The installer reads the bot token using ordinary terminal input and writes it directly to `config.yaml`. It does not set `umask 077`, create the file with mode `0600`, or apply a restrictive permission after creation. Consequently, the resulting permissions depend on the user's current umask. Under permissive local settings, the token may be readable by other users or processes. The token is also visible while it is entered because `read -s` is not used. The bot token is security-sensitive because it authenticates Telegram API requests and permits polling updates sent to the bot. ### Attack Path 1. The operator runs `install.sh` under a permissive umask. 2. The installer writes the Telegram token to `~/.autopilot/config.yaml`. 3. The resulting file is group-readable or world-readable. 4. Another local user or compromised process reads the file. 5. The attacker uses the token to impersonate the bot, inspect bot updates, or interfere with notification and command processing. ### Impact Assessment A stolen token can permit unauthorized use of the Telegram bot identity and API. Depending on Telegram state and configuration, an attacker may: - Poll updates intended for the legi ...[truncated 378 chars]
Remediation: View remediation

T08 · Insecure Dependencies

Note

Location: requirements.txt:1
Finding: Unbounded PyYAML Dependency Produces Non-Reproducible Installations
Content: View full analysis
=5.0 ``` ### Technical Analysis The project accepts any PyYAML release newer than or equal to version 5.0. It does not provide an upper bound, exact reviewed version, lock file, or package hash. This does not prove that a malicious dependency is currently installed. However, it makes installations non-reproducible and allows future releases to be selected automatically. A compromised, incompatible, or unexpectedly changed release could therefore enter the runtime without a source-code change in this project. PyYAML processes project task configuration, so dependency behavior is relevant to a security-sensitive parsing boundary. ### Attack Path 1. An operator installs dependencies at a later date or in a new environment. 2. The package resolver selects the newest release satisfying `pyyaml>=5.0`. 3. That release contains an incompatible change, vulnerability, or supply-chain compromise. 4. Autopilot imports and executes the selected package while loading project task definitions. 5. The affected dependency behavior runs with the Autopilot user's privileges. ### Impact Assessment The immediate confirmed impact is loss of installation reproducibility and reviewability. A future dependency compromise could potentially affect all Python Autopilot operations under the current user's account. There is no evidence in the audited repository of dependency confusion, typosquatting, or a currently malicious PyYAML version; this finding concerns unsafe version management. ]]>
Remediation: View remediation

SkillSpector

Vulnerability Patterns

MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (263)

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The supplied code chunk does not implement or support the declared automation system. It only parses a markdown task plan file and reports completion status. Its primary purpose is task-plan completion validation, which is materially different from managing tmux-based Codex CLI sessions or any watchdog/orchestration behavior described. No evidence appears of tmux interaction, launchd integration, session management, queue dispatch, review automation, or related triggers.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The declared description describes a complex automation/orchestration system for Codex CLI sessions using tmux and launchd. The supplied code does none of that. It only creates three markdown planning/progress files in the current directory and prints next-step instructions. There is no tmux interaction, no background loop, no launchd integration, no session management, no queue processing, and no code review or compaction logic. This is a clear description-behavior mismatch with a materially different primary purpose.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 98% confidence
Finding: The declared description describes a broad automation/orchestration system for multiple Codex CLI sessions using tmux and launchd. The supplied code does not implement any of those core behaviors. Instead, it is a session catch-up utility that reads local AI assistant session logs from ~/.claude or ~/.gemini, identifies where planning files were last edited, extracts later conversation context, and prints a recovery summary. While both involve AI coding sessions and context, the code’s primary purpose is retrospective context reconstruction for one project, not active multi-session automation or watchdog control. This is a material description-behavior mismatch.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The declared description specifies a substantial automation/orchestration system with many concrete capabilities. However, the supplied code chunk is only a placeholder init.py file containing a comment and no functional code. Therefore, the actual behavior does not substantiate the declared purpose, making this a clear description-behavior mismatch.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 98% confidence
Finding: The declared description presents a broad orchestration system for managing multiple Codex CLI sessions in tmux with launchd/watchdog behavior. The supplied code chunk is instead a focused GUI message-sending helper for the Codex desktop app on macOS. Its primary function is clipboard-based UI automation through AppleScript/System Events and CGEvent keyboard injection, which is materially different from tmux session monitoring and multi-project automation. The code also accesses resources not implied by the description, such as the system clipboard and macOS accessibility/UI automation interfaces. This is a clear description-to-behavior mismatch.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 98% confidence
Finding: The supplied code chunk is narrowly focused on validating 'done' conditions for a task: checking whether files exist and meet size/content constraints, whether glob patterns match enough files, and whether specified shell commands return expected exit codes. This is materially different from the declared system description of a tmux/launchd-based multi-session Codex automation orchestrator. The code does not interact with tmux, launchd, Codex sessions, queues, watchdog loops, or review/context-management mechanisms. Additionally, it includes command execution capability via subprocess, which is not reflected in the declared description for this component. Therefore, the description does not accurately represent the behavior of this code chunk.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 96% confidence
Finding: The supplied code chunk is a narrow text-classification component, not an automation system. It does not interact with tmux, launchd, processes, multiple projects, queues, permissions, or session management. While it does include detection of review-like output and could plausibly support a watchdog/orchestration system as an internal helper, the declared description presents a much broader operational automation capability than this code actually implements. Therefore the description does not accurately represent this code chunk's actual behavior.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 98% confidence
Finding: The supplied code does not implement any tmux, launchd, Codex CLI, watchdog, session orchestration, queue management, review automation, or permission-management behavior described in the declared purpose. Instead, it performs filesystem scanning and milestone progress reporting for software projects. This is a materially different primary purpose, not merely a supporting component of the declared automation system, based on the code chunk alone.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The supplied code chunk is narrowly focused on generating reply text templates and orchestration-related messages for a Codex-like workflow. It contains functions for intent-based replies, nudges, failed-done-condition messages, next-task prompts, all-tasks-complete notices, and human review notices. While some small overlap exists with the declared system concept—such as generating nudges and task/review-related messages—this module does not implement the primary declared behavior of a tmux + launchd watchdog automation system. There is no code for tmux control, launchd integration, monitoring loops, session management across projects, permission handling, context compaction, or queue dispatch. Therefore the description materially overstates and misrepresents what this specific code chunk actually does.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 95% confidence
Finding: The supplied code is a task dependency and state orchestration module, not a tmux/launchd-based Codex CLI automation system. Its actual functionality is limited to parsing tasks.yaml, tracking per-task status, checking dependencies, generating contextual prompts, dispatching ready tasks, handling manual approval gates, and reporting progress. While 'dispatches tasks from a queue' is partially consistent with the description, the major declared capabilities—session monitoring, tmux integration, launchd watchdog behavior, nudging idle sessions, permission management, context compaction, and code review loops—are absent from this code chunk. Therefore the description materially overstates and misrepresents what this code actually does.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 98% confidence
Finding: The supplied code does not implement the declared primary functionality of tmux/launchd-based Codex session watchdog automation. Instead, it provides a Telegram integration layer for receiving and handling remote bot commands over the Telegram API. While some commands operate on project/session/task state consistent with a broader multi-project automation system, the code chunk’s actual behavior is specifically a networked Telegram bot control surface, which is not disclosed in the description. This is a materially different and undeclared capability, especially because it introduces external network access and remote control triggers unrelated to the declared tmux/watchdog automation description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 98% confidence
Finding: The supplied code does not implement the declared core behavior of tmux/launchd-based Codex session orchestration, watchdog monitoring, idle nudging, permission handling, context compaction, code review, or task queue dispatch. Instead, it is a standalone notification module that sends messages to Telegram over HTTP using bot credentials and chat IDs. While the notification templates reference 'Autopilot' and project status, that only suggests it may support a larger automation system; this code chunk itself primarily provides Telegram messaging functionality, which is an undeclared capability and materially different primary purpose from the description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 93% confidence
Finding: The declared description presents a multi-project tmux/launchd watchdog system centered on monitoring Codex CLI sessions, nudging idle sessions, handling permissions, compacting context, running reviews, and dispatching queued tasks. This code chunk does not implement session monitoring or tmux orchestration. Instead, it is a specialized fallback runner that substitutes another agent when Codex limits are exhausted, constructs a prompt from project files, runs openclaw agent to perform the task, inspects git history for new commits, sends Telegram notifications, and updates queue/state files. While task-queue interaction and automation themes are adjacent to the broader system, this specific code’s primary purpose and capabilities are materially different from the declared behavior.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 97% confidence
Finding: The supplied code chunk implements a narrow maintenance task: synchronizing state.json with configured projects by deleting stale project data. It only performs local file I/O on config and state files and path/name validation. This is materially different from the declared purpose of a multi-project tmux/launchd Codex automation system with watchdog behavior and orchestration features. While state cleanup could be a supporting utility within such a system, this specific chunk does not actually exhibit the declared core behaviors, so the description does not accurately represent what this code chunk does.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The code’s actual purpose is materially different from the declared description. It does not automate or orchestrate Codex CLI sessions; instead, it reads historical session log files, parses token_count events, aggregates token usage by project, and emits a machine-readable JSON report. While both relate to Codex and projects, the declared system is an active multi-session tmux/launchd automation/watchdog framework, whereas this script is a passive analytics/reporting tool. The filesystem access to ~/.codex/sessions is consistent with Codex usage, but the primary behavior and capabilities are substantially mismatched.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The supplied code chunk does not implement the declared tmux/watchdog/Codex session automation behavior. Its primary purpose is Discord notification delivery. While window-name mapping could be tangentially related to tmux workflows, the core behavior is sending outbound Discord messages using a bot token and the Discord API, which is a distinct capability not described in the declared purpose. Therefore this is a clear description-behavior mismatch.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The supplied code chunk does not implement or expose behavior aligned with the declared automation system. Instead, it is a simple wrapper script for a Python-based PRD verification engine. There is no evidence of tmux interaction, launchd integration, watchdog looping, Codex session management, queue handling, or review/context automation. This is a materially different primary purpose, so the description does not accurately represent the code.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The declared description describes an orchestration/automation system for supervising multiple Codex CLI sessions via tmux and launchd. The supplied code does none of that. Its primary purpose is validating PRD items from a YAML file against checks, generating a JSON report, optionally running shell commands as verification steps, and syncing a markdown todo file. This is a materially different function, with different resources and outputs. The mismatch is clear and substantial, not just a missing feature or implementation detail.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The declared description describes an automation/orchestration system centered on tmux, launchd, Codex session management, watchdog behavior, and task dispatch. The supplied code does none of that. It is a focused file-processing utility: it reads a markdown review file, extracts P0/P1 table rows, maps priorities to severities, updates a PRD items YAML document with bugfix entries, and prints a JSON summary. This is a materially different primary purpose and capability set from the declared description, so it should be flagged as a mismatch.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The declared description describes a substantial automation/orchestration system with multiple concrete capabilities. The supplied code chunk is only a minimal tests/init.py file containing a comment and no executable logic. Because the actual code does not implement or evidence the declared functionality, the description does not accurately represent this code chunk. The mention of 'Codex Desktop Autopilot' also suggests a different component name/context than the declared tmux + launchd multi-project Codex CLI automation system.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The supplied code does not implement or exercise a tmux/launchd-based Codex automation system. Instead, it is a test suite for completion-condition checking utilities. Its observable behavior is limited to unit-testing file checks, glob checks, shell command checks, aggregation of 'done' conditions, and formatting of results. While command execution is present in tests, it is only for validating a checker utility, not for orchestrating Codex sessions or automation workflows. Therefore the actual code's primary purpose is materially different from the declared description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The supplied code chunk is only a test suite for a natural-language intent analyzer. It imports analyze_intent and asserts expected classifications for various Chinese and English phrases. There is no evidence of tmux interaction, launchd integration, watchdog loops, Codex CLI session management, queue handling, permission workflows, or project orchestration. The code’s primary purpose is materially different from the declared description, so this is a clear mismatch.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The supplied code does not implement the declared automation system itself. It is a test suite focused narrowly on scheduler behavior and project state management. While some concepts overlap with multi-project orchestration (project loading, scheduling, lifecycle, cooldowns), the actual code chunk neither monitors tmux/Codex sessions in a watchdog loop nor performs launchd integration, nudging, permission handling, context compaction, code reviews, or queue dispatch. The primary purpose of the code chunk is testing scheduler logic, which is materially different from the declared end-user skill description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 97% confidence
Finding: The supplied code does not implement the declared automation/orchestration system. It is only a test module validating two narrow behaviors in a session monitor library: time-based session state classification and extraction of the last assistant message from JSONL files. While these tests may support a broader Codex session management system, this specific chunk neither manages tmux/launchd nor automates multiple projects, dispatches tasks, runs reviews, or performs watchdog actions. Therefore the chunk’s actual behavior is materially narrower and different from the declared purpose.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 98% confidence
Finding: The supplied code does not implement or exercise the declared tmux/launchd Codex automation workflow. Instead, it is narrowly focused on unit tests for a state manager: counters, cooldown timing, daily limits, project state lookup, history logging, and persistence to a state file. While such state tracking could be a supporting component of a larger automation system, this chunk’s actual behavior is materially different from the declared primary purpose and does not show the advertised monitoring/orchestration capabilities.
Content: No source excerpt is available for this finding.