Codex Autopilot

• Outcome: Review
• Latest audit: Sep 11, 2026 · 4:03 AM UTC
• Version: 0.7.1

Overview

This skill is an autonomous coding-agent watchdog that is mostly purpose-aligned, but it can run persistently and approve or execute high-impact actions without enough user control.

Install only if you are comfortable with an unattended coding agent that can operate on configured repositories. Before use, disable automatic permanent approvals and yolo/full-auto modes, review all task and PRD command checks, protect Telegram/Discord tokens, and run it under a low-privilege account or disposable project-scoped sandbox.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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 (5)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: scripts/permission-guard.sh:84
• Finding: Automatic Permanent Approval Bypasses Agent Permission Boundaries<![CDATA[ ## Vulnerability Details **File Location**: `scripts/permission-guard.sh:84-98`; related behavior in `scripts/watchdog.sh:198-219` and `scripts/watchdog.sh:1110-1127` **Vulnerability Type**: Automatic permission approval and unrestricted agent execution **Risk Level**: High ### Vulnerable Code ```bash tail_content=$($TMUX capture-pane -t "${SESSION}:${window}" -p 2>/dev/null | tail -8) || return if is_permission_prompt "$tail_content"; then ( flock -n 200 || { log "⏭ Skipped ${window} (locked)"; exit 0; } local recheck recheck=$($TMUX capture-pane -t "${SESSION}:${window}" -p 2>/dev/null | tail -8) || exit 0 if is_permission_prompt "$recheck"; then $TMUX send-keys -t "${SESSION}:${window}" "p" Enter set_cooldown "$safe_name" log "✅ Auto-approved permission in ${window}" fi ) 200>"${LOCK_DIR}/${safe_name}.lock" fi ``` The related Gemini startup logic defaults to unrestricted approval: ```bash # Gemini approval mode: yolo (auto-approve all), auto_edit, default GEMINI_APPROVAL_MODE="${GEMINI_APPROVAL_MODE:-yolo}" # ... tmux send-keys -t "$gemini_window" \ "${cd_cmd}${GEMINI} --approval-mode ${GEMINI_APPROVAL_MODE}" Enter ``` ### Technical Analysis The permission guard monitors terminal output and automatically sends `p` followed by Enter when a matching permission prompt appears. Based on the comments and matching rules, `p` represents permanent approval. Separately, the Gemini integration defaults to `yolo`, which automatically approves agent actions. This removes the human authorization boundary intended to protect filesystem access, shell execution, package installation, network requests, and other sensitive operations. Pattern matching and a second pane-content check reduce accidental keystrokes, but they do not determine whether the requested operation is safe. Continuous task routing requires the ability to submit tasks, but it does not inherently req ...[truncated 1644 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove permanent automatic approval. Never send `p` automatically. 2. Change the default Gemini mode from `yolo` to `default` or another interactive restricted mode. 3. Require explicit user confirmation for: - File deletion or overwrite operations. - Package installation and lifecycle scripts. - Network access or uploads. - Credential and configuration-file access. - Commands outside the configured project directory. 4. If limited auto-approval is necessary, parse and validate the requested operation against a strict allowlist rather than matching only generic prompt text. 5. Run coding agents in a sandbox with: - A dedicated low-privilege account. - A project-scoped filesystem mount. - No SSH, cloud, messaging, or keychain credentials. - Restricted outbound network access. 6. Make approval events visible and auditable, recording the exact command, resource, decision, and policy rule. 7. Require an explicit configuration flag and prominent warning before enabling any automatic approval feature. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: lib/done_checker.py:181
• Finding: Arbitrary Shell Command Execution Through Repository Task Completion Checks<![CDATA[ ## Vulnerability Details **File Location**: `lib/done_checker.py:181-202`; command definitions are loaded by `lib/task_orchestrator.py:123-160` and invoked by `autopilot.py:253-259` **Vulnerability Type**: Shell command injection from task configuration **Risk Level**: High ### Vulnerable Code ```python cmd = cmd_spec.get("cmd", "") expect_exit = cmd_spec.get("expect_exit", 0) # Replace the {project_dir} placeholder cmd = cmd.replace("{project_dir}", project_dir) # Simplified command for logging short_cmd = cmd if len(cmd) <= 50 else cmd[:47] + "..." try: result = subprocess.run( cmd, shell=True, capture_output=True, timeout=COMMAND_TIMEOUT, cwd=project_dir ) ``` Task configuration is loaded from YAML without restricting command contents: ```python with open(tasks_yaml_path, 'r', encoding='utf-8') as f: data = yaml.safe_load(f) # ... tasks_data = data.get("tasks", []) for task_data in tasks_data: task = Task.from_dict(task_data) config.tasks.append(task) ``` The completion check is automatically invoked after the agent reports task completion: ```python if intent == Intent.TASK_COMPLETE: logger.info(f"检测到任务完成意图，验证完成条件...") default_min_size = tasks_config.get_default("min_file_size", 100) done_result = check_done_conditions( current_task.done_when, project_dir, default_min_size ) ``` ### Technical Analysis The `cmd` field from a task YAML file is passed as a single string to `subprocess.run(..., shell=True)`. Shell metacharacters, command substitutions, pipelines, redirections, and chained commands are therefore interpreted by the user's shell. The `{project_dir}` substitution is also performed as raw text without shell quoting. A path containing shell-significant characters can alter the command even when the configured command otherwise appears benign. Because task files can exist inside monitored projects, treating them as trusted executable policy crea ...[truncated 1491 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace string commands with explicit argument arrays: ```python result = subprocess.run( validated_argv, shell=False, cwd=validated_project_dir, capture_output=True, timeout=COMMAND_TIMEOUT, check=False, ) ``` 2. Define a schema in which each check specifies an executable and separate arguments. 3. Permit only an allowlist of verification tools and safe argument patterns. 4. Reject shell operators and constructs, including `;`, `&&`, `||`, `|`, redirects, backticks, and `$()`. 5. Resolve and validate the working directory, ensuring it remains within an explicitly configured project root. 6. Do not substitute project paths into command strings. Pass paths as individual arguments or use `cwd`. 7. Treat repository-provided task files as untrusted. Require explicit local approval before enabling executable checks. 8. Execute checks in a sandbox without user credentials and with restricted filesystem and network access. 9. Log the complete normalized argument list before execution and provide a dry-run mode. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: lib/input_sender.py:337
• Finding: Shell Injection Through Unquoted Project and Session Values Sent to tmux<![CDATA[ ## Vulnerability Details **File Location**: `lib/input_sender.py:337-360`; related occurrences in `install.sh:181-200` and `scripts/watchdog.sh:216-219` **Vulnerability Type**: Unsafe construction of shell commands **Risk Level**: Medium ### Vulnerable Code ```python # Create window codex_cmd = f"cd {project_dir} && {codex} resume {session_id} --full-auto" if not session_exists and i == 0: subprocess.run( [tmux, 'new-session', '-d', '-s', TMUX_SESSION, '-n', name, '-c', project_dir], capture_output=True, timeout=5 ) subprocess.run( [tmux, 'send-keys', '-t', f'{TMUX_SESSION}:{name}', codex_cmd, 'Enter'], capture_output=True, timeout=5 ) session_exists = True else: subprocess.run( [tmux, 'new-window', '-t', TMUX_SESSION, '-n', name, '-c', project_dir], capture_output=True, timeout=5 ) subprocess.run( [tmux, 'send-keys', '-t', f'{TMUX_SESSION}:{name}', codex_cmd, 'Enter'], capture_output=True, timeout=5 ) ``` The installer uses the same unsafe pattern for configured project paths: ```bash $TMUX new-window -t "$SESSION" -n "$w" $TMUX send-keys -t "${SESSION}:${w}" "cd $d" Enter ``` The Gemini startup path also constructs shell text: ```bash local cd_cmd="" [ -n "$project_dir" ] && cd_cmd="cd ${project_dir} && " tmux send-keys -t "$gemini_window" \ "${cd_cmd}${GEMINI} --approval-mode ${GEMINI_APPROVAL_MODE}" Enter ``` ### Technical Analysis Although the `tmux` subprocess itself is invoked with an argument array, the value sent through `send-keys` is interpreted later by the interactive shell running inside the tmux pane. Consequently, this is still a shell command-construction vulnerability. Values such as `project_dir`, `session_id`, and executable paths are interpolated without shell-safe quoting. If an attacker can influence one of these values, shell metacharacters can terminate or extend the intended comm ...[truncated 1464 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not construct shell command strings and submit them with `tmux send-keys`. 2. Start the intended process directly through a controlled wrapper using argument arrays. 3. If pane-based startup is unavoidable, use a fixed audited launcher script and pass dynamic values through validated environment variables or safely quoted arguments. 4. Apply POSIX-safe quoting to every dynamic value; Python may use `shlex.quote()` as defense in depth. 5. Validate: - Project directories as existing canonical absolute paths. - Session identifiers against a strict character allowlist. - Window names against a strict character allowlist. - Executable paths as approved local binaries. 6. Reject values containing control characters, newlines, shell operators, or command substitutions. 7. Remove `--full-auto` and `yolo` defaults so that injected or malformed startup behavior cannot proceed without review. 8. Add tests covering spaces, quotes, semicolons, substitutions, newlines, and other shell-significant path content. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: install.sh:102
• Finding: Telegram Bot Token Is Collected and Stored Without Explicit File Protection<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:102-115` **Vulnerability Type**: Plaintext credential handling with insufficient permission enforcement **Risk Level**: Medium ### Vulnerable Code ```bash if [ -f "$CONFIG_YAML" ] && grep -q 'bot_token' "$CONFIG_YAML" 2>/dev/null; then ok "Telegram 配置已存在 (config.yaml)" else info "配置 Telegram 通知 (可选, 直接回车跳过)" 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 配置已保存" else warn "跳过 Telegram 配置" fi fi ``` ### Technical Analysis The installer accepts a Telegram bot token using ordinary terminal input, so the token is displayed while it is typed. It then stores the credential in plaintext YAML without first setting a restrictive umask or explicitly applying mode `0600`. The actual file permissions therefore depend on the invoking user's environment and existing file state. On a system with a permissive umask or pre-existing insecure file permissions, other local accounts or processes may be able to read the token. The project needs access to a token to provide its declared Telegram functionality, but exposing the token during input and failing to enforce restrictive storage permissions are not necessary for that functionality. ### Attack Path 1. A user runs the installer and enters a Telegram bot token. 2. The token is displayed on the terminal and may be exposed to shoulder surfing, terminal recording, or session capture. 3. The installer writes the token to `~/.autopilot/config.yaml`. 4. If the resulting file is group-readable or world-readable, another local user or compromised process reads it. 5. The attacker uses the token to impersonate the bot or interact with the Telegram Bot API within the token's capabilities. ### Impact Assessment Exposure of the bot token can perm ...[truncated 600 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Disable terminal echo when collecting the token: ```bash read -rsp " Bot Token: " tg_token echo ``` 2. Set a restrictive umask before creating any credential file: ```bash umask 077 ``` 3. Create the configuration atomically and enforce permissions: ```bash chmod 600 "$CONFIG_YAML" ``` 4. Verify that `~/.autopilot` is not group-writable or world-writable. 5. Prefer storing the token in macOS Keychain and retrieving it at runtime. 6. If plaintext configuration remains supported, separate secrets from ordinary project configuration. 7. Avoid logging token-containing URLs or full exception details that could include request information. 8. Document token rotation and immediate revocation procedures. 9. Ensure the Telegram command listener refuses to start unless an explicit non-empty chat-ID allowlist is configured. ]]>

T08 · Insecure Dependencies

Note

• Location: requirements.txt:1
• Finding: Unbounded PyYAML Dependency Produces Non-Reproducible and Unverified Installations<![CDATA[ ## Vulnerability Details **File Location**: `requirements.txt:1` **Vulnerability Type**: Unpinned third-party dependency **Risk Level**: Low ### Vulnerable Code ```text pyyaml>=5.0 ``` ### Technical Analysis The dependency declaration accepts any PyYAML release at or above version 5.0. It provides no upper bound, exact version, lock file, or integrity hash. This does not demonstrate that the current dependency is malicious. However, it makes installations non-reproducible and allows future releases to be selected without repository review. It also complicates vulnerability management because different installations can silently receive different versions. Python package installation may run package build logic, so uncontrolled dependency resolution expands supply-chain exposure. ### Attack Path 1. A user installs the project dependencies at a later date. 2. The package resolver selects the newest PyYAML release satisfying `>=5.0`. 3. That release may contain a newly introduced vulnerability, incompatible behavior, or compromised distribution artifact. 4. Installation or runtime parsing occurs within the Autopilot environment. 5. The affected dependency behavior compromises reliability or security. This is a supply-chain hardening issue rather than evidence of an active malicious package in the audited repository. ### Impact Assessment Potential impact depends on the defect or compromise in the resolved package and may include: - Arbitrary code execution during package build or installation. - Runtime denial of service or parsing vulnerabilities. - Unexpected behavior caused by incompatible releases. - Inconsistent security posture across installations. - Difficulty reproducing and auditing deployed environments. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin PyYAML to a reviewed exact version. 2. Generate a lock file using a reproducible dependency-management tool. 3. Require package hashes, for example through a hash-locked requirements file. 4. Run dependency vulnerability scanning in CI. 5. Review and deliberately update pinned versions on a controlled schedule. 6. Prefer binary wheels from trusted package indexes and restrict package index configuration. 7. Record the supported Python version and platform to make dependency resolution reproducible. ]]>

SkillSpector

Vulnerability Patterns

• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (236)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The code does support parts of the description: tmux-based Codex session management, watchdog-style periodic execution, multi-project scheduling, task orchestration from tasks.yaml, context/reply generation, Telegram command handling, and send verification. However, the declared purpose centers on a multi-model automation system with Codex and Gemini role separation, intelligent task routing by type, and built-in CI/CD/test-agent behavior. In the supplied code, all orchestration is around Codex sessions only; there is no Gemini integration, no model-selection/routing logic, no test runner/CI execution loop, no automatic failure-detection-and-fix queue, and no coverage ratchet. The code’s actual primary purpose is a deprecated Codex autopilot/watchdog for session nudging and task progression, not the broader multi-model CI/CD automation system claimed.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The supplied code chunk is specifically an installation/setup script, not the orchestration engine described. It provisions directories, collects optional Telegram credentials, stores project configuration, validates companion scripts, creates tmux windows, installs a persistent launchd watchdog service, and verifies deployment. While some elements loosely align with the description (tmux session management, watchdog setup, task-queue directory creation, Codex-oriented workflow), the key advertised capabilities—intelligent multi-model routing, Gemini integration, CI/CD/test-agent automation, code review, context compaction, and automatic task fixing—are absent from this code. The code also performs undeclared setup actions such as Telegram configuration and macOS launch agent installation. Therefore the description does not accurately represent what this code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description promises a large, feature-rich automation system, but the provided code chunk is only an empty module initializer containing a comment. There is no implemented behavior corresponding to the claimed orchestration, routing, testing, or CI/CD capabilities. This is therefore a material mismatch between the declared purpose and the actual code shown.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The supplied code does not implement the declared orchestration platform features such as multi-model routing, tmux session management, watchdog loops, CI/CD, task queues, code review, or test-agent behavior. Instead, it is a focused desktop-input automation helper for sending messages to the Codex app on macOS. This is a materially different primary purpose and introduces undeclared capabilities involving GUI automation, clipboard access, and synthetic keyboard events. While such a sender might support a larger automation system, this code chunk itself is not accurately represented by the declared description.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The supplied code chunk does not implement the declared system's primary functionality. Instead of orchestrating concurrent AI coding sessions or routing tasks across models, it only evaluates whether completion criteria are met using filesystem checks and command execution. While command-based checks could support a larger CI/testing workflow, this module by itself is a narrow validation utility, not a multi-model automation platform. It also executes shell commands in the project directory, which is a specific behavior not reflected in the high-level description of this chunk. Therefore the description materially overstates and misrepresents what this code actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 89% confidence
• Finding: The declared description presents a broad autonomous orchestration system spanning multiple models, routing, testing, and CI/CD. The supplied code chunk implements a much narrower support layer: sending input to Codex sessions via tmux or CLI, inspecting tmux state, verifying responses through file-size changes, and setting up tmux windows for Codex resume sessions. These behaviors are related to session management, but they do not substantiate the major declared capabilities such as Gemini/frontend routing, watchdog-driven automation, queue-based dispatch, code review, or test/coverage automation. Therefore the description materially overstates what this code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The supplied code does not implement the declared system-level automation/orchestration behavior. It only analyzes text content from Codex output and returns an intent label based on heuristics. While this could be a supporting component inside a larger watchdog automation framework, the code chunk itself does not perform session orchestration, task routing across models, tmux control, CI/CD, queue management, testing automation, or coverage enforcement. The declared description therefore materially overstates what this code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The supplied code chunk only scans a project filesystem and summarizes progress against inferred milestones based on the presence of files such as package.json, Cargo.toml, pyproject.toml, and matching source/test globs. It formats progress and identifies remaining milestones. It does not interact with AI models, tmux, queues, test runners, CI/CD systems, or any automation loop. This is a materially different primary purpose from the declared description, so the description does not accurately represent the code.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description promises a large automation/orchestration system for managing multiple AI coding sessions, routing tasks by model/type, running CI/CD and tests, and continuously driving development workflows. The supplied code chunk does none of that. It only generates human/agent reply messages based on an Intent enum and some task-completion/review metadata. While some functions mention task orchestration concepts (done checks, next task, human review), they merely format response text and do not implement the advertised automation capabilities. This is a clear description-behavior mismatch with a materially different primary purpose.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: The supplied code implements only a narrow monitoring layer for local Codex session logs. It reads files under ~/.codex/sessions, extracts session IDs from filenames, caches cwd metadata from session_meta records, classifies sessions as ACTIVE/IDLE/DONE based on mtime thresholds, and parses recent JSONL entries to determine whether the last message came from the user or to retrieve the last assistant response. While such monitoring could support a larger automation system, this chunk does not itself orchestrate multiple AI models, manage tmux sessions, route tasks by type, run CI/CD, or operate a test/fix/coverage loop as described. Therefore the declared description materially overstates and misrepresents the actual behavior of this code chunk.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The supplied code is a narrow task orchestration/state-management module, not the full multi-model coding automation platform described. It loads task definitions, checks dependency cycles, marks tasks complete/running, blocks tasks requiring human review, builds prompts with dependency context, and selects the next ready task. While this partially aligns with phrases like 'task dispatch' and 'context passing,' it does not implement the description's central capabilities: no Codex/Gemini model routing, no frontend/backend classification, no tmux orchestration, no watchdog-driven loop, no CI/CD/test execution, no auto-detection of failures, no auto-fix queueing, and no coverage ratchet logic. The declared purpose therefore materially overstates and misrepresents what this code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The code chunk is not the described core orchestration engine. It does not manage tmux sessions, route tasks between Codex and Gemini, run CI/CD, compact context, dispatch from a priority queue, or perform automated test-agent remediation. Instead, it provides a Telegram control surface for an existing system: polling Telegram via getUpdates, filtering allowed chat IDs, parsing slash commands, sending replies, and invoking project-state handlers like pause/resume/status/tasks/log. While some commands interact with project/task orchestration state and therefore may support the broader automation system, the actual code’s primary purpose is a Telegram bot interface, which is an undeclared capability and materially different from the declared description.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The supplied code chunk does not implement AI coding orchestration, tmux session management, task routing, watchdog loops, CI/CD automation, test-agent behavior, or coverage ratcheting. Its primary purpose is outbound Telegram notification delivery. While the notification templates reference 'Autopilot' and 'Codex status,' that is only labeling/formatting and does not provide the declared automation capabilities. This is a clear description-behavior mismatch because the code’s actual function is a standalone notifier component accessing Telegram network resources, which are not reflected in the declared description.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The declared description presents a broad automation/orchestration system for multiple AI coding agents with task routing, tmux session control, queueing, watchdog behavior, and automated testing/fixing workflows. The supplied code chunk is much narrower: it is a local auto-check helper script that performs lint/type/security-style checks and optionally nudges a tmux session with findings. The tmux nudge is only a small supporting behavior and does not substantiate the larger claimed capabilities such as multi-model routing, CI/CD orchestration, queue dispatch, or autonomous test-agent coverage ratcheting. Therefore, the code chunk does not accurately represent the declared system and is a material mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: The supplied code does not implement the declared core functionality of a multi-model coding automation system. There is no evidence here of orchestrating Codex/Gemini sessions, task routing by frontend/backend, priority queues, code review loops, CI/CD execution, test failure detection, auto-fix enqueueing, or coverage ratcheting. Instead, this chunk is a support library focused on parsing config.yaml entries, mapping Discord channels to tmux windows/project directories, sending Telegram messages, and providing timeout/lock helpers. Some of these may support a larger autopilot system, but this code chunk by itself has a materially different purpose and also includes undeclared messaging capabilities.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The supplied code's primary function is branch lifecycle management for Git repositories: validating repos, resolving base branches, creating namespaced task branches, persisting branch state, marking merge readiness, attempting auto-merge with conflict handling, and cleaning up expired branch artifacts. It does not implement the declared system's hallmark behaviors such as orchestrating concurrent AI coding sessions, tmux management, backend/frontend model routing, queue-based task dispatch, automatic testing/fix loops, or coverage ratcheting. While branch isolation could be a supporting feature within a larger automation platform, this specific code chunk is materially different in purpose and capabilities from the declared description, so this is a clear mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The supplied code does not implement the broad declared system features such as tmux orchestration, Codex/Gemini routing, watchdog loop, CI/CD, incremental code review, or test-agent coverage ratcheting. Instead, it is a narrowly focused fallback executor used when Codex quota is exhausted, switching work to a Claude/OpenClaw agent. It also performs specific side effects not mentioned in the description, including sending Telegram notifications, reading project context files to build prompts, checking for git commits, writing debug/state logs, and marking queue tasks complete. While this script may belong to a larger automation ecosystem, this code chunk’s actual behavior is materially different from the declared purpose.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The supplied code only implements cleanup of stale project metadata in a JSON state file based on entries in a YAML config. It loads configuration, normalizes project paths/names, removes invalid entries from several state fields, and atomically saves the updated state. This is materially different from the declared description of a sophisticated AI coding automation platform with session orchestration, routing, and continuous testing. The code does touch files named config.yaml and state.json, which could be part of a larger automation system, but this chunk itself is merely a housekeeping script and does not exhibit the declared core capabilities.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description describes a complex automation platform for managing concurrent AI coding sessions, routing tasks by model/type, and running continuous testing and fixing workflows. The supplied code does none of that. It is a reporting script focused on reading local Codex session logs, extracting token_count events, attributing them to projects by cwd, and producing daily JSON usage summaries. While it does interact with Codex-related data, that is only for accounting/telemetry, not orchestration or automation. 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 supplied code chunk is narrowly focused on coverage collection and test-package inspection. It reads workspace/package metadata, detects test frameworks, parses Istanbul, Node test, JaCoCo, and Bats outputs, and aggregates monorepo coverage into JSON. It does not orchestrate AI agents, manage tmux sessions, route frontend/backend tasks to different models, dispatch from a priority queue, or implement a watchdog loop or auto-fix behavior. While coverage collection could be a supporting component within a larger automation system, this code chunk itself does not match the declared primary purpose and capabilities.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description is about orchestrating multiple AI coding agents, routing tasks, managing CI/CD, test automation, and tmux-based coding sessions. The supplied code does none of that directly. Its primary function is to post notifications to Discord channels. While Discord notifications could be a supporting utility in a larger automation system, this specific code chunk implements a distinct capability—outbound Discord messaging using a bot token and channel mappings—that is not represented in the declared purpose. Therefore, the description does not accurately represent what this code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a broad AI coding automation platform with intelligent task routing, Codex/Gemini orchestration, CI/CD, queue dispatching, testing, and coverage ratcheting. The supplied code does not implement those behaviors. Instead, it is a narrowly focused permission guard daemon that monitors tmux windows and auto-confirms detected permission dialogs by sending 'p' and Enter. While tmux and an 'autopilot' session are mentioned in both, the actual primary purpose is materially different and includes an undeclared capability: automatic permission approval. This is not merely a supporting detail of the declared system; it is a distinct operational behavior absent from the description.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a comprehensive AI coding automation platform with model orchestration, task routing, testing, and CI/CD behaviors. This code chunk does not implement any of those core capabilities. Instead, it performs a specific watchdog-related maintenance task: determining when to trigger a PRD audit for each project and writing trigger files for another agent to process. While the comments mention watchdog triggering, that is only a small supporting relation to the declared system; the primary behavior here is PRD audit scheduling/triggering, which is materially different and undeclared. Therefore this chunk does not accurately match the stated description.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description promises a complex AI coding automation platform with model routing, tmux-managed concurrent sessions, watchdog behavior, queue dispatch, code review, and test auto-fix capabilities. The supplied code chunk does none of that directly: it is only a shell wrapper that validates the existence of a Python file and execs it with arguments. Based on this chunk alone, the actual purpose is to invoke a PRD verification engine. That is a materially different primary purpose from the declared description, so this should be flagged as a mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description and the actual code are materially different. The description promises a complex AI coding automation platform that manages concurrent Codex/Gemini sessions, routes tasks by model/domain, runs watchdog loops, and performs autonomous testing/fixing workflows. The supplied code instead implements a PRD/item verification engine for project artifacts. It parses YAML, merges inherited version definitions, filters entries, runs simple verification plugins, emits a JSON report, and optionally updates markdown todo checkboxes. While command execution is present, it is only as a verification check mechanism and not as CI/CD orchestration or AI workflow management. This is a clear purpose and capability mismatch, with the added undeclared capability of running shell commands from configuration.

Static analysis

Detected: suspicious.dynamic_code_execution

Dynamic code execution detected.

Critical

• Code: suspicious.dynamic_code_execution
• Location: scripts/auto-check.sh:72