T01 · Skill Instruction Hijacking
- Location
resources/o.md:48- Finding
Untrusted Remote MCP Resources Can Replace Agent Instructions and Persona
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This project-creation skill is coherent for Orchestrix automation, but it installs persistent agent hooks, auto-approves trust or approval prompts, and may commit a license key into Git history.
Review carefully before installing. Only use this in a repository where you intentionally want Orchestrix to install Claude Code hooks, run multi-agent tmux automation, and activate MCP-provided agents. Do not provide a real license key unless .mcp.json is ignored or kept out of commits, and manually review any trust or approval prompts instead of relying on the included auto-accept behavior.
resources/o.md:48Untrusted Remote MCP Resources Can Replace Agent Instructions and Persona
resources/start-orchestrix.sh:294Automation Bypasses Claude Code Trust and Approval Prompts
resources/handoff-detector.sh:114Unauthenticated Terminal Output Is Converted into Cross-Agent Commands
SKILL.md:318Plaintext License Credential Is Included in the Initial Git Commit
Beyond creating files, the skill installs hooks, modifies agent configuration, manages multi-agent tmux sessions, and auto-accepts safety/trust interactions. That is materially broader than 'create project' and can establish persistent automation inside the new workspace, which users may not understand from the title and description alone.
Beyond creating files, the skill installs hooks, modifies agent configuration, manages multi-agent tmux sessions, and auto-accepts safety/trust interactions. That is materially broader than 'create project' and can establish persistent automation inside the new workspace, which users may not understand from the title and description alone.
Beyond creating files, the skill installs hooks, modifies agent configuration, manages multi-agent tmux sessions, and auto-accepts safety/trust interactions. That is materially broader than 'create project' and can establish persistent automation inside the new workspace, which users may not understand from the title and description alone.
Beyond creating files, the skill installs hooks, modifies agent configuration, manages multi-agent tmux sessions, and auto-accepts safety/trust interactions. That is materially broader than 'create project' and can establish persistent automation inside the new workspace, which users may not understand from the title and description alone.
The skill writes into the agent configuration area under .claude and installs a hook script there, which can alter future agent behavior inside the workspace. Modifying agent config and hook paths is sensitive because it creates persistent execution surfaces that may run automatically later, not just during initial setup.
# Claude Code hooks 配置
cp "$RESOURCE_DIR/settings.local.json" "$PROJECT_DIR/.claude/settings.local.json"
# Hook 脚本
cp "$RESOURCE_DIR/handoff-detector.sh" "$PROJECT_DIR/.claude/hooks/handoff-detector.sh"
The instruction to automatically accept Claude Code 'trust this directory' prompts bypasses an important security boundary intended to let users assess whether a workspace should be trusted. Auto-approving that decision can enable execution of hooks, config, and other workspace-controlled behaviors without informed user consent.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
__pycache__/
# Environment
.env
.env.local
.env.*.local
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Environment
.env
.env.local
.env.*.local
# OS
Automatically accepting a trust or safety prompt without notifying the user defeats the purpose of the prompt and can silently place the environment into a more trusted execution mode. Because this skill scaffolds and initializes workspaces, the user is likely to assume safe setup behavior, making the hidden acceptance more security-relevant rather than less.
This is a true vulnerability: the script is presented as a passive completion monitor, but it actively sends approval input to a tmux pane whenever a matching prompt indicator is seen. That can authorize unintended actions by an agent or tool running in the pane, bypassing human review and turning a status-check helper into an execution/consent primitive.
Automatically sending 'y' to an interactive prompt without user warning or confirmation is unsafe because it may approve destructive, privileged, or externally triggered operations. In a tmux-driven agent workflow, any mistaken prompt detection or maliciously induced prompt can result in silent authorization of actions the user never reviewed.
The script intentionally targets the project's .claude settings directory to persist a Stop hook. Accessing and modifying agent configuration is security-sensitive because it changes how the agent behaves in future runs and can introduce automatic command execution in response to agent events.
# Inject handoff-detector hook into target project
# ============================================
# CRITICAL: The tmux agents run Claude Code in WORK_DIR, so their Stop hooks
# come from WORK_DIR/.claude/settings*.json, NOT from the orchestrix-mcp-server project.
# We must inject the handoff-detector hook into the target project's settings.local.json
# so that agent Stop events trigger local handoff detection.
SETTINGS_LOCAL="$WORK_DIR/.claude/settings.local.json"
The HANDOFF_HOOK_CMD value is written into .claude/settings.local.json as a command hook, creating a persistent execution path that runs shell commands in the repository context. In a project scaffolding skill this is more dangerous because users may expect setup automation, making it easier to hide or normalize sensitive agent-config changes.
# come from WORK_DIR/.claude/settings*.json, NOT from the orchestrix-mcp-server project.
# We must inject the handoff-detector hook into the target project's settings.local.json
# so that agent Stop events trigger local handoff detection.
SETTINGS_LOCAL="$WORK_DIR/.claude/settings.local.json"
HANDOFF_HOOK_CMD="bash -c 'cd \"\$(git rev-parse --show-toplevel)\" && .orchestrix-core/scripts/handoff-detector.sh'"
# Ensure .claude directory exists
The script detects Claude Code trust or safety prompts and programmatically presses Enter to accept them without user review. That defeats an important security control intended to prevent execution in untrusted folders, allowing agents and hooks to run in repositories the user has not consciously approved.
Automatically approving trust or safety dialogs removes a deliberate human checkpoint designed to protect users from running agents in unsafe contexts. In this skill, that is especially dangerous because the same script also injects hooks and starts multiple automated agent sessions, compounding the consequences of trusting the wrong repository.
The skill performs shell-based filesystem operations, copies scripts, changes permissions, and initializes git, yet it declares no explicit tool scope or allowed-tools boundary. That increases the chance the agent can invoke broader shell capabilities than the user expects, especially because the workflow writes into home-directory project paths and installs executable hooks/scripts.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
---
name: create-project
description: "Interactive Orchestrix project scaffolding. Creates project directory under ~/Codes/, generates project brief from Q&A, installs MCP config, hooks, slash commands, tmux scripts, and initializes git. Use when user wants to create a new project, init a project, or start a new Orchestrix workspace."
license: MIT
metadata:
author: dorayo
The activation text is broad enough to trigger on common requests like starting or initializing a project, even though the skill performs extensive writes, installs hooks/scripts, and may lead into session automation. Overbroad invocation increases the chance of accidental execution in contexts where the user did not intend those side effects.
The description does not clearly warn that the skill will make extensive filesystem changes, install executable scripts/hooks, and initialize a git repository. Missing side-effect disclosure reduces informed consent and makes the later automation-related behavior more dangerous in context.
The skill asks for a license key and plans to store it in .mcp.json without a clear privacy or retention warning. Users may provide a real credential without realizing it will be written to disk in project state, where it can be committed or exposed to other tools.
The skill collects an Orchestrix license key and writes it into project configuration despite presenting itself as local scaffolding. Storing secrets in generated project files creates unnecessary exposure risk through local leaks, backups, screenshots, commits, or later automation reading those files.
The instructions explicitly require "用中文提问," which imposes a specific language policy on the interaction. There is no opt-in, fallback, or user choice documented, so this is a natural-language policy violation under the language/locale rule.
The script explicitly detects trust/safety-related text in a tmux pane and sends Enter to auto-accept it, bypassing a security gate intended to require user review. In the context of a project-creation skill, this is especially dangerous because newly created or reopened project folders may contain unreviewed code or configuration, and the automation removes the user's chance to assess that risk.
The dev path changes into the project directory and executes .orchestrix-core/scripts/start-orchestrix.sh in the background. While a comment notes session recreation, there is no visible user-facing warning, prompt, or logging about this subprocess execution and its potential effects.
The script changes .orchestrix-core/runtime/pending-handoff.json by marking its status as completed, which is a file write affecting project state. Although comments describe the behavior, there is no user-facing disclosure, confirmation, or prompt before this modification occurs.
No suspicious patterns detected.