Back to skill

Security audit

Code Tmux

Security checks for vulnerabilities and agentic risk

Overview

This skill has a coherent coding-workflow purpose, but it launches persistent coding agents with reduced safeguards and automatically exposes environment files that may contain secrets.

Review carefully before installing. Use this only if you intentionally want coding agents running in persistent tmux sessions, remove the dangerous Claude permission-bypass flag, avoid linking full `.env` files unless absolutely required, and verify worktree/session state before cleanup.

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 (4)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:35
Finding
Delegated Agent Runs with Permission Checks Disabled<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:35`; `references/troubleshooting.md:9` **Vulnerability Type**: Permission bypass and excessive agent privileges **Risk Level**: High ### Vulnerable Code ```bash cd <project> # worktree + tmux in one command: claude -w <branch-name> --tmux --dangerously-skip-permissions ``` The troubleshooting instructions repeat the unsafe option: ```bash tmux send-keys -t <session> "nvm use 20 && claude --dangerously-skip-permissions" Enter ``` ### Technical Analysis The `--dangerously-skip-permissions` option disables Claude Code's normal permission confirmation controls. Git worktree isolation only separates repository branches and working directories; it does not restrict the agent's access to the host filesystem, user credentials, processes, network, or other repositories. Consequently, a delegated coding agent can perform host-user-level operations without an interactive authorization boundary. Repository instructions, source comments, issue descriptions, or other attacker-controlled context processed by the agent may induce it to run commands unrelated to the legitimate coding task. ### Attack Path 1. An attacker places adversarial instructions in repository content or another input consumed during a coding task. 2. The Skill launches Claude Code with `--dangerously-skip-permissions`. 3. The delegated agent processes the attacker-controlled instructions. 4. The agent runs shell commands or accesses resources without requesting permission. 5. Those operations execute with the privileges and resource access of the user running OpenClaw or Claude Code. ### Impact Assessment Successful exploitation can provide access equivalent to the host account running the agent. Depending on that account's environment, the affected scope may include local files, source repositories, SSH configuration, cloud credentials, developer tokens, running processes, and network-accessible services. The reviewed Skill does no ...[truncated 114 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove `--dangerously-skip-permissions` from both the primary workflow and troubleshooting instructions. - Retain normal per-operation permission prompts for filesystem, shell, and network activity. - Run delegated agents inside an OS-level sandbox or container with an explicit filesystem allowlist. - Restrict network access unless it is required by the approved task. - Use a dedicated, unprivileged operating-system account without access to unrelated repositories or user credentials. - Require explicit user confirmation for destructive commands, credential access, package installation, and operations outside the task worktree. - Document that Git worktrees provide source-control isolation, not a security sandbox. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:48
Finding
Secret-Bearing Environment Files Are Automatically Exposed to Delegated Agents<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:48-49`, `SKILL.md:127`; `references/troubleshooting.md:23` **Vulnerability Type**: Unnecessary credential exposure through symbolic links **Risk Level**: High ### Vulnerable Code ```bash # Symlink env files ln -sf <project>/.env <worktree-path>/.env ln -sf <project>/.env.local <worktree-path>/.env.local # if exists ``` The behavior is mandatory under the Skill rules: ```text - **Always** symlink `.env` files — don't copy ``` The troubleshooting guide reinforces the same behavior: ```bash ln -sf <project>/.env <worktree-path>/.env ``` ### Technical Analysis Files named `.env` and `.env.local` commonly contain API keys, database credentials, signing secrets, service tokens, and other sensitive configuration. The Skill exposes these files to every delegated agent workspace without determining whether the task requires them. Because symbolic links point to the original files, access is not limited to a disposable copy. A process operating in the worktree can read the original secrets and may also modify or truncate the source file if filesystem permissions permit it. The risk is compounded by launching Claude Code with permission checks disabled. No direct exfiltration command was identified in the reviewed project. The vulnerability is the unnecessary exposure of sensitive data to an unrestricted, network-capable delegated process. ### Attack Path 1. A project contains credentials in `.env` or `.env.local`. 2. The Skill creates symbolic links to those files inside the new worktree. 3. A delegated agent, repository script, dependency, or attacker-controlled instruction accesses the linked path. 4. The process reads the credentials or modifies the original environment file through the symbolic link. 5. Read credentials may then be used against the services for which they are valid; network-capable tooling could also transmit them externally. ### Impact Assessment The exposed privileges de ...[truncated 357 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove the rule requiring `.env` and `.env.local` to be linked automatically. - Require explicit, per-task user authorization before exposing any sensitive configuration. - Supply only the individual variables required for the approved task rather than the complete environment file. - Prefer short-lived, least-privilege credentials dedicated to the sandboxed task. - If configuration files are required, provide redacted example files or read-only copies containing non-production values. - Prevent delegated agents from modifying source credential files. - Apply filesystem and network sandboxing so that access to a worktree does not imply access to unrelated credentials or external destinations. - Record and display which secrets or variables will be exposed before starting the delegated agent. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:43
Finding
Unvalidated Values Are Submitted to Interactive Shell Sessions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:43-54`, `SKILL.md:60-65`, `SKILL.md:82-96`, `SKILL.md:106-110` **Vulnerability Type**: Command injection through unsafe command construction and terminal input forwarding **Risk Level**: High ### Vulnerable Code ```bash # Create worktree git -C <project> worktree add -b <branch> <worktree-path> main # Symlink env files ln -sf <project>/.env <worktree-path>/.env ln -sf <project>/.env.local <worktree-path>/.env.local # if exists # Create tmux session and launch agent tmux new-session -d -s <task-name> -c <worktree-path> tmux send-keys -t <task-name> "nvm use 20 && <tool-command>" Enter ``` Task content and later user responses are also submitted into the terminal session: ```bash tmux send-keys -t <session-name> -l -- "Your task here. Before making any changes, show me a plan of what you intend to do and wait for my approval." sleep 0.1 tmux send-keys -t <session-name> Enter ``` ```bash tmux send-keys -t <task-name> -l -- "<user response>" sleep 0.1 tmux send-keys -t <task-name> Enter ``` ### Technical Analysis The workflow interpolates project paths, worktree paths, branch names, tmux session names, a remembered tool command, task text, and user responses without specifying strict validation or shell-safe encoding. The Skill permits the selected tool to be “any CLI tool name,” and then inserts that value after `nvm use 20 &&`. `tmux send-keys -l` prevents tmux from interpreting the supplied text as key names, but it does not prevent a foreground shell from interpreting shell metacharacters after the separate `Enter` submission. If the expected interactive agent has exited, failed to start, or returned control to a shell, forwarded task or response text can become a shell command. Likewise, an attacker-controlled or corrupted remembered tool preference can contain shell syntax rather than a single allowlisted executable. Unquoted template values used in worktree and tmux setup commands a ...[truncated 1405 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Replace arbitrary CLI selection with an explicit allowlist mapping stable identifiers such as `claude` or `codex` to fixed executable paths and fixed argument arrays. - Reject tool names, branch names, worktree paths, and session names that do not match narrowly defined formats. - Use APIs that pass executable arguments directly without invoking a shell wherever possible. - Quote and terminate options for all path and identifier arguments; reject leading-dash identifiers where the receiving command permits option confusion. - Verify the foreground process in the tmux pane before forwarding any text. - Stop and request user intervention if the agent exits, the pane returns to a shell, or process identity cannot be established. - Do not submit arbitrary responses followed by `Enter` to an unverified terminal state. - Use a structured IPC mechanism or supported agent API instead of terminal keystroke injection. - Treat stored preferences as untrusted data and validate them every time they are consumed. ]]>

T08 · Insecure Dependencies

Warning
Location
README.md:20
Finding
Installation Executes a Mutable Unpinned Package Release<![CDATA[ ## Vulnerability Details **File Location**: `README.md:20` **Vulnerability Type**: Unpinned installation-time dependency execution **Risk Level**: Medium ### Vulnerable Code ```bash npx clawhub@latest install claude-code-tmux ``` ### Technical Analysis The documented installation command uses `npx` to fetch and execute the mutable `latest` version of the `clawhub` package. The effective package contents can change after this Skill has been reviewed. The project provides no exact version pin, integrity digest, lockfile, signature-verification step, or reproducible installation procedure for this command. This does not establish that the current package is malicious. It creates a supply-chain exposure in which compromise of the package, publisher account, registry, or future release can introduce code that is not represented in the audited project files. ### Attack Path 1. An attacker compromises the package publication account, registry distribution path, or a future `latest` release. 2. The attacker publishes a modified package under the version resolved by the `latest` tag. 3. A user follows the README installation command. 4. `npx` downloads and executes the newly resolved package. 5. Malicious installation code runs with the privileges of the invoking user before the user can inspect the effective payload. ### Impact Assessment A compromised package executed through `npx` can perform arbitrary actions available to the invoking account, including reading local files and credentials, modifying installed Skills, altering repositories, or making network requests. The exposure occurs during installation and is not constrained by the worktree controls described elsewhere in the project. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Replace `@latest` with an exact, reviewed package version. - Publish and verify an integrity hash for the installation artifact. - Prefer a lockfile-backed or otherwise reproducible installation process. - Use signed release artifacts and document signature verification. - Review package lifecycle scripts and transitive dependencies before recommending execution. - Consider a two-step process that downloads the artifact for inspection and verifies its digest before executing it. - Establish an update process in which new package versions are audited before the pinned version is changed. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (14)

Intent-Code Divergence

High
Confidence
98% confidence
Finding
The skill claims changes will only occur after a plan is shown and approved, but the Claude invocation uses --dangerously-skip-permissions, which disables an important execution safeguard. In a coding-agent workflow, that mismatch can allow file modifications or command execution before meaningful human review, especially if the agent receives a malformed or adversarial task.

Missing User Warnings

High
Confidence
96% confidence
Finding
The skill documentation omits a clear warning that the recommended Claude command runs in dangerous permission-bypass mode. Users may reasonably assume normal safeguards apply, leading them to approve use of a workflow that can act with fewer checks than expected.

Credential Access

High
Category
Privilege Escalation
Content
git -C <project> worktree add -b <branch> <worktree-path> main

# Symlink env files
ln -sf <project>/.env <worktree-path>/.env
ln -sf <project>/.env.local <worktree-path>/.env.local   # if exists

# Create tmux session and launch agent
Confidence
97% confidence
Finding
Symlinking the project's .env into the agent worktree grants the coding agent direct access to sensitive credentials that may not be necessary for the task. If the agent is compromised, manipulated by prompt injection, or simply verbose in logs/output, those secrets can be exfiltrated or misused.

Credential Access

High
Category
Privilege Escalation
Content
# Symlink env files
ln -sf <project>/.env <worktree-path>/.env
ln -sf <project>/.env.local <worktree-path>/.env.local   # if exists

# Create tmux session and launch agent
tmux new-session -d -s <task-name> -c <worktree-path>
Confidence
97% confidence
Finding
Symlinking .env.local similarly exposes local secrets, developer-specific tokens, and possibly production credentials to the coding tool running in the worktree. Because local env files often contain the most privileged or least-reviewed secrets, this raises the risk of credential theft and lateral movement.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
```
Either remove the existing worktree first, or use a different branch name:
```bash
git worktree remove /tmp/task-x
# then retry
```
Confidence
80% 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
```
Either remove the existing worktree first, or use a different branch name:
```bash
git worktree remove /tmp/task-x
# then retry
```
Confidence
80% 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).

Credential Access

High
Category
Privilege Escalation
Content
# then retry
```

## .env not found in worktree

```bash
ln -sf <project>/.env <worktree-path>/.env
Confidence
84% confidence
Finding
The guidance instructs users to symlink the main project's `.env` into a secondary worktree, which can propagate secrets into additional execution contexts and tools. In a skill designed to run coding agents in persistent tmux sessions across isolated worktrees, that increases the chance that credentials are exposed to agent processes, logs, shell history, or unintended code running in the worktree.

Credential Access

High
Category
Privilege Escalation
Content
## .env not found in worktree

```bash
ln -sf <project>/.env <worktree-path>/.env
```

## tmux session already exists
Confidence
83% confidence
Finding
The repeated `.env` reference reflects the same unsafe pattern: copying access to environment secrets into an isolated worktree used by persistent coding agents. Because this skill explicitly supports automated coding tools operating in those worktrees, the context makes the exposure more dangerous than ordinary local troubleshooting guidance.

Rp1

Medium
Category
MCP Rug Pull
Confidence
95% confidence
Finding
The README instructs users to install the skill via `npx clawhub@latest install claude-code-tmux`, which pulls and executes the latest published package without pinning to a specific trusted version. If the upstream package is compromised, typosquatted, or a malicious version is published, users could execute attacker-controlled code during installation. In a developer tool that manages code and shells out to tmux/CLI agents, this supply-chain exposure is more dangerous because the target audience is likely to run the command locally with access to source code and credentials.

Vague Triggers

Medium
Confidence
96% confidence
Finding
The activation description is broad enough to trigger on common requests such as build, fix, refactor, or review code, which increases the chance this high-privilege workflow is invoked by default. Because the skill launches persistent agent sessions and may expose repository secrets or perform edits, overbroad activation materially expands attack surface and misuse likelihood.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The skill instructs symlinking .env and .env.local into agent worktrees without warning that this exposes live credentials and secrets to whichever coding tool is launched there. In an interactive agent setting, this can unnecessarily broaden secret access and increase the blast radius of prompt injection, tool compromise, or accidental disclosure.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The cleanup steps remove worktrees without warning about preserving or checking for uncommitted changes first. In a persistent coding workflow, that can lead to accidental loss of in-progress work or destruction of forensic evidence after an unsafe agent action.

Missing User Warnings

Low
Confidence
89% confidence
Finding
The document instructs users to run `git worktree remove /tmp/task-x` in two places as a troubleshooting step. Although one later note says the branch is preserved, the instructions do not clearly warn that the worktree directory itself will be removed and that uncommitted changes in that worktree could be affected.

Missing User Warnings

Low
Confidence
84% confidence
Finding
The troubleshooting instructions include `tmux kill-session -t <name>`, which forcibly terminates an existing session and may discard in-progress interactive state. The markdown does not warn the user that this is destructive or advise verifying that the session can be safely removed before running it.

Static analysis

No suspicious patterns detected.