T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:174- Finding
Unattended Agent Execution Can Modify and Publish Repository Content Without Review
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is transparent about delegating coding work, but it repeatedly encourages unattended agents that can edit, commit, and push code without a review checkpoint.
Install only if you are comfortable delegating repository edits to Cursor Agent. Prefer --plan or interactive mode first, use isolated temporary worktrees, inspect git status and diffs before committing, and require a separate explicit decision before any push or PR creation. Avoid --yolo, --trust, background execution, and broad project directories unless you understand the account and credential access available to the agent.
SKILL.md:174Unattended Agent Execution Can Modify and Publish Repository Content Without Review
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).
gh pr create --repo user/repo --head fix/issue-78 --title "fix: ..." --body "..."
git worktree remove /tmp/issue-78 git worktree remove /tmp/issue-99
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).
git worktree remove /tmp/issue-78 git worktree remove /tmp/issue-99
---
The skill's safety boundary is inconsistent: metadata explicitly says to never spawn agents in ~/clawd workspace, but the later rules only forbid ~/.openclaw/. That contradiction can cause an operator or downstream agent to treat the narrower path as the real restriction and run a powerful coding agent in a sensitive workspace the top-level description intended to protect.
The skill says PR reviews should be done in a temp directory for isolation, but the later batch-review example launches review agents in ~/project. This undermines the documented isolation model and may expose unrelated local code or secrets to the reviewing agent while allowing accidental writes in a non-ephemeral workspace.
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.
For longer tasks, use background mode:
# Start background task
bash pty:true workdir:~/project background:true command:"agent --yolo 'Refactor the auth module'"
# Returns sessionId, monitor with process tool
Documenting a --yolo/--force flag that auto-approves all operations enables autonomous decision-making by the coding agent with reduced oversight. In this skill context, that increases the chance of unintended file, git, or shell actions being carried out before a user can review them.
| Flag | Description |
|------|-------------|
| `prompt` | Initial prompt for the agent |
| `--yolo` / `--force` | Auto-approve all operations (dangerous but fast) |
| `--model <model>` | Specify model (gpt-5, sonnet-4, opus-4, gemini, grok, etc.) |
| `--workspace <path>` | Working directory |
| `-w, --worktree [name]` | Run in isolated git worktree |
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.
| `--mode <mode>` | Execution mode: plan (read-only planning), ask (Q&A) |
| `--plan` | Plan mode (read-only, no file modifications) |
| `--cloud` | Cloud mode |
| `--resume` | Resume previous session |
| `--trust` | Trust workspace (headless mode only) |
---
The dedicated 'Auto-Execute Mode (--yolo)' section promotes autonomous execution of coding tasks in a real project directory. Because this skill is specifically for delegating code changes, the example materially increases the risk of unsupervised repository modifications rather than describing a harmless capability.
bash pty:true workdir:~/project command:"agent 'Build a dark mode toggle'"
### Auto-Execute Mode (--yolo)
```bash
# Auto-approve all operations, fast execution
bash pty:true workdir:~/project command:"agent --yolo 'Refactor the auth module'"
The example explicitly frames auto-approve as a fast execution path, which encourages bypassing review controls. In a tool that can edit files and run commands, this can lead to unintended destructive or security-impacting changes with little friction.
# Auto-approve all operations, fast execution
bash pty:true workdir:~/project command:"agent --yolo 'Refactor the auth module'"
The example instructs the agent to auto-approve changes, commit, and push to origin without an explicit warning or human checkpoint. In a coding-agent skill, that can directly modify repositories and publish unintended or unsafe code, making the side effects materially dangerous rather than merely illustrative.
The rules section elevates '--yolo for building' to a normative recommendation, effectively making auto-approval part of the expected workflow. That guidance is dangerous in this context because it nudges operators toward unattended code changes by a powerful external agent.
1. **Always use pty:true** - Will hang without PTY
2. **Use background for long tasks** - Don't block main thread
3. **--yolo for building** - Auto-approve changes
4. **--plan for reviewing** - Read-only analysis
5. **--print for scripting** - Non-interactive, parseable output
6. **Use -w worktree for isolation** - Parallel task processing
The completion-notification example tells the spawned agent to execute a host command when it finishes. Even though the example is for notification, it normalizes agent-directed host command execution and could be repurposed for arbitrary commands if copied without scrutiny.
No suspicious patterns detected.