codex-orchestration
WarnAudited by ClawScan on May 10, 2026.
Overview
This skill is openly an orchestration helper, but it asks the agent to run parallel background Codex workers with no approvals and possible persistence, so it should be reviewed before enabling.
Install this only if you intentionally want Codex to manage parallel background workers. Prefer using it in a sandbox or trusted repository, keep approvals or confirmations enabled, limit worker count and runtime, monitor active sessions, avoid passing secrets into worker prompts, and clean up any temporary files or tmux/nohup jobs.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
When invoked, the agent may start command-line worker processes or web-enabled tasks without asking the user to approve each action.
The skill tells the agent to operate as if shell/PTY execution and web access are available without approvals. Combined with general-purpose orchestration, this materially weakens per-action user control over high-impact commands.
Default assumptions - YOLO config (no approvals); web search enabled. - PTY execution available via `exec_command` and `write_stdin`.
Use only in a trusted sandbox or repository, keep human approvals enabled where possible, and require explicit user consent before starting workers or running commands that can change files or systems.
Background jobs could keep running after the main response, consume resources, or continue acting in the user’s workspace unless monitored and stopped.
The skill encourages detached or long-running worker processes and even suggests persistent runners, but the visible instructions do not define hard timeouts, cleanup rules, or a required user approval gate.
Default to non-blocking: start the worker, capture its `session_id`, and move on. ... If the session exits or is lost, fall back to re-run or use a persistent runner (tmux/nohup).
Require session tracking, timeouts, explicit stop/cleanup steps, and user approval before using tmux/nohup or leaving any worker running after the turn.
Project details or sensitive context included in worker prompts may be copied into multiple agent sessions or temporary output files.
The workflow passes task context to multiple worker agents and stores worker outputs in files. This is expected for the skill, but the visible instructions do not specify secret filtering, retention, or data-boundary rules.
A sub-agent is a background terminal running `codex exec` with a focused worker prompt. ... Use `--output-last-message` to write the final response to a file, then read it.
Avoid sending secrets to workers, keep context packs minimal, and delete temporary worker output files after use.
The skill may fail or behave differently depending on which local tools are present and how they are configured.
The skill depends on external commands and optional helpers, while the registry requirements declare no required binaries. This is an operational/provenance gap rather than evidence of hidden code.
Example: `codex exec --json "CONTEXT: WORKER ..." | jq -r ...` ... use a persistent runner (tmux/nohup).
Confirm the exact Codex CLI and helper tools being used before enabling the skill, and prefer pinned or trusted local installations.