T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:23- Finding
Delegated Agents Are Instructed to Bypass Permission Controls and Sandboxing
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a real coding-agent delegation guide, but it routinely encourages bypassed approvals, unsandboxed execution, and remote repository actions that users should review carefully before installing.
Install only if you understand that this skill can lead your agent to launch other coding agents with broad file, command, network, and repository authority. Use it in disposable worktrees or containers, avoid --yolo and permission-bypass modes unless explicitly intended, do not paste untrusted issue text into shell commands, and review before any commit, push, PR comment, or global package install.
SKILL.md:23Delegated Agents Are Instructed to Bypass Permission Controls and Sandboxing
SKILL.md:214Unescaped Task Text Can Break Out of Shell-Quoted Agent Commands
SKILL.md:190Unpinned Global Installation of a Third-Party Coding Agent
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 Claude Code guidance instructs use of --permission-mode bypassPermissions, which disables an important safeguard, but the text frames it as the correct approach rather than a high-risk exception. This encourages routine permission bypass and lowers operator caution around potentially dangerous file and command actions.
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 statement that workdir means the agent 'sees only this folder's context' is misleading because the documented commands also allow broader filesystem and network actions, including elevated execution and unsandboxed modes. This can cause operators to overtrust directory scoping and launch agents under a false assumption of confinement.
The --full-auto flag is described as auto-approving changes, which delegates decision-making about modifications to the coding agent without review at execution time. While safer than --yolo, it still creates a real risk of unintended edits or actions when used as a recommended default for building tasks.
| 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
The skill recommends --full-auto and documents --yolo as available behavior without requiring a strong user warning at the point of use. Auto-approved or no-approval execution enables unattended code and environment changes, increasing the chance of destructive edits, data exposure, or unintended command execution.
Documenting --yolo as 'NO sandbox, NO approvals' and associating it with speed makes fully autonomous unsandboxed execution an endorsed workflow. In a coding-agent skill, that materially increases the chance of arbitrary system changes, secret exposure, or destructive actions beyond the project boundary.
| --------------- | -------------------------------------------------- |
| `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
The example actively demonstrates codex exec --full-auto for feature building, operationalizing autonomous approvals rather than merely mentioning them. This makes risky unattended modification behavior easy to copy-paste into real projects without a balancing warning.
# 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
The examples normalize autonomous remote side effects such as posting GitHub comments, committing, and pushing changes without a clear warning that these actions modify external systems and may disclose data. In a delegation skill, this can lead to accidental publication of sensitive code, noisy automation, or unauthorized repository activity.
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 rule '--full-auto for building' institutionalizes autonomous approvals as standard practice for creation tasks. That increases risk because build tasks often involve dependency changes, file creation, test execution, and command invocation that can have broader effects than users expect.
- 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 delegated coding agents to invoke openclaw system event on the host when they finish, which expands the agent's capability from code editing into host-level signaling. That creates an unintended cross-boundary side effect channel and could be abused to generate spoofed notifications, trigger orchestration behavior, or mask malicious activity as normal completion events.
No suspicious patterns detected.