T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:23- Finding
Permission Controls and Sandboxing Disabled for Delegated Coding Agents
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a disclosed coding-agent launcher, but it repeatedly recommends running delegated agents with disabled approvals or sandboxing in ways users should review carefully before installing.
Install only if you are comfortable supervising delegated coding agents that may run with broad local authority. Prefer sandboxed modes, disposable clones or containers, pinned dependencies, and separate human review before commits, pushes, PR comments, or any command that uses local credentials.
SKILL.md:23Permission Controls and Sandboxing Disabled for Delegated Coding Agents
SKILL.md:214Unpinned and Potentially Script-Executing Dependency Installation
Skill reads from agent configuration directories (.claude/, .codex/, .gemini/). These directories may contain API keys, personal settings, and other credentials that the skill has no legitimate need to access.
## Codex CLI
**Model:** `gpt-5.2-codex` is the default (set in ~/.codex/config.toml)
### Flags
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 recommends claude --permission-mode bypassPermissions --print as the correct way to run Claude Code, effectively disabling permission checks for a delegated coding agent. Although the text mentions an alternative failure mode, it does not provide an adequate safety warning or compensating controls for granting unrestricted tool access.
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 quick prompts/chats, create a temp git repo and run:
# Quick chat (Codex needs a git repo!)
The skill describes --full-auto as auto-approving changes in the workspace, which reduces human oversight over agent actions. While less severe than --yolo because it remains sandboxed, it still encourages autonomous modifications that can introduce unsafe or unintended changes.
| Flag | Effect |
| --------------- | -------------------------------------------------- |
| `exec "prompt"` | One-shot execution, exits when done |
| `--full-auto` | Sandboxed but auto-approves in workspace |
| `--yolo` | NO sandbox, NO approvals (fastest, most dangerous) |
### Building/Creating
Documenting --yolo as 'NO sandbox, NO approvals' endorses fully autonomous execution without safety interlocks. In the context of a coding-agent skill that spawns background processes in real project directories, this materially increases the risk of destructive edits, data exposure, or unintended command execution.
| --------------- | -------------------------------------------------- |
| `exec "prompt"` | One-shot execution, exits when done |
| `--full-auto` | Sandboxed but auto-approves in workspace |
| `--yolo` | NO sandbox, NO approvals (fastest, most dangerous) |
### Building/Creating
This concrete example operationalizes --full-auto for building in a real project directory, normalizing unattended code changes. The danger is amplified because examples are likely to be copied verbatim by operators, turning reduced-oversight behavior into the default workflow.
# Quick one-shot (auto-approves) - remember PTY!
bash pty:true workdir:~/project command:"codex exec --full-auto 'Build a dark mode toggle'"
# Background for longer work
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 fixing multiple issues in parallel, use git worktrees:
# 1. Create worktrees for each issue
git worktree add -b fix/issue-78 /tmp/issue-78 main
git worktree add -b fix/issue-99 /tmp/issue-99 main
The rules section explicitly recommends --full-auto for building, reinforcing autonomous approval as standard operating procedure. Repetition in policy-style guidance makes misuse more likely and weakens operator caution around agent autonomy.
- If an agent fails/hangs, respawn it or ask the user for direction, but don't silently take over.
3. **Be patient** - don't kill sessions because they're "slow"
4. **Monitor with process:log** - check progress without interfering
5. **--full-auto for building** - auto-approves changes
6. **vanilla for reviewing** - no special flags needed
7. **Parallel is OK** - run many Codex processes at once for batch work
8. **NEVER start Codex in ~/.openclaw/** - it'll read your soul docs and get weird ideas about the org chart!
The skill instructs spawned agents to run openclaw system event on completion, which is unrelated host-control functionality rather than task-local coding work. This creates an unintended command-execution bridge from the delegated agent back into the orchestrator environment, enabling spoofed completion signals or abuse of host capabilities if the agent follows or mutates that instruction.
The documentation claims workdir keeps the agent focused and limits wandering, but elsewhere recommends permissive modes such as --yolo and bypass-permissions that undermine that implied boundary. This can mislead operators into believing directory scoping is a meaningful security control when the agent may still act with broad authority.
No suspicious patterns detected.