Are Codex skills safe? What a skill can do and how to review one

The short answer

A skill is mostly text. Codex reads it and follows it, which means a skill can do anything Codex itself is allowed to do in your session, and nothing more. The protections that matter are the ones around Codex: the sandbox, the approval policy and your own review. With Codex’s default settings and a skill you have read, the risk is low. With full access and a skill you have not read, it is not.

What a skill can do

Part	What it can do	What limits it
Instructions in SKILL.md	Tell Codex to read files, edit code, run commands, call tools	Everything Codex does is subject to the sandbox and approvals
scripts/	Run as ordinary commands when the instructions call them	Same sandbox and approval policy as any command
references/, assets/	Add text and files to context	Nothing executes on its own
agents/openai.yaml	Set UI metadata, turn implicit use on or off, declare an MCP server dependency	Codex can prompt to install a declared MCP server; you choose

Plugins can carry more: MCP servers that act on external services and hooks that run at lifecycle points. Hooks that are not admin-managed must be reviewed and trusted before they run. Treat a plugin as a bundle of everything it contains.

What contains a skill: sandbox and approvals

Codex separates two controls. The sandbox decides what spawned commands can technically do. The approval policy decides when Codex must stop and ask.

The sandbox covers every command Codex starts, not just its own file edits. A skill script, git, npm install or a test runner all inherit the same limits. It is enforced by the operating system: Seatbelt on macOS, bubblewrap on Linux and WSL2, and a native sandbox on Windows.

Setting	Effect on skills
read-only	Scripts can read but not write. Default for codex exec.
workspace-write (the usual interactive default)	Writes allowed inside the workspace; network off unless enabled; .git, .agents, .codex and .aws stay read-only
danger-full-access	No sandbox. A skill’s scripts can do anything your user account can
approval_policy = "on-request"	Codex asks before crossing the sandbox boundary, such as network access or writing outside the workspace
approval_policy = "never"	No prompts; Codex works within whatever the sandbox allows
--yolo (--dangerously-bypass-approvals-and-sandbox)	No sandbox and no approvals

Note the protected paths. Under workspace-write, a .agents directory inside the workspace is read-only, so a task cannot quietly rewrite the repository’s skills without asking.

Codex also has an approval category specifically for skill scripts. With a granular approval policy you can decide whether those prompts surface at all:

approval_policy = { granular = { sandbox_approval = true, rules = true, mcp_elicitations = true, request_permissions = true, skill_approval = true } }

Setting skill_approval = false auto-rejects skill-script approval prompts instead of showing them, which is a reasonable choice for unattended runs.

Where the real risk is

Instructions as an attack. A skill’s text is effectively a prompt with high trust. A hostile skill does not need a script; it can tell Codex to “upload the coverage report” to a URL that collects your .env. The sandbox blocks network access by default, but if you approve the request without reading it, it goes through.

Scripts you did not read. A script that “formats the output” can also delete files in the workspace, which workspace-write allows.

Secrets in the environment. Codex’s automatic filter for variable names containing KEY, SECRET or TOKEN is off by default (ignore_default_excludes defaults to true), so an exported AWS_SECRET_ACCESS_KEY can reach any script a skill runs. Turn the filter on:

[shell_environment_policy]
ignore_default_excludes = false

Updates. A skill you reviewed last month is not the skill you have today if an installer or git pull replaced it. Re-review on update.

Full-access sessions. With danger-full-access or --yolo, every risk above has no backstop. Use those only inside a disposable container or VM, never with unreviewed skills installed.

Review a third-party skill in five minutes

1. Read the whole SKILL.md. Look for instructions to contact URLs, read credential files, change shell profiles, disable checks, push code, or “not mention” something to the user.

2. List every file. Anything executable or unexpected deserves a look:

   find ./some-skill -type f | sort

3. Search for network and credential access:

   grep -rnE 'curl|wget|https?://|requests\.|fetch\(|nc |ssh |scp ' ./some-skill
   grep -rnE '\.env|id_rsa|\.aws|\.ssh|token|secret|password|keychain' ./some-skill
   grep -rnE 'base64|eval|exec\(|\$\(curl' ./some-skill

4. Read every script top to bottom. If you cannot follow one, do not install it.

5. Check agents/openai.yaml. Note any declared MCP dependency and where it points.

6. Decide the invocation mode. If the skill has side effects, prefer explicit $name use. If you maintain a fork, set allow_implicit_invocation: false.

The security-hardening skill applies a similar checklist to your whole Codex setup, and supply-chain-security covers the broader dependency side.

Settings that limit the damage

A conservative ~/.codex/config.toml for working with skills you are still evaluating:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
web_search = "cached"

[sandbox_workspace_write]
network_access = false

[shell_environment_policy]
ignore_default_excludes = false

When a workflow genuinely needs the network, prefer enabling it for that task over turning it on globally, and consider the network proxy with a domain allowlist. For specific commands, rules can allow, prompt or forbid a command prefix outside the sandbox.

For automation, keep codex exec at its read-only default unless the job must write, and use --sandbox workspace-write rather than full access. See codex-sandbox-approvals for choosing per task.

Supply-chain hygiene for skills

• Prefer sources you can identify. A named publisher with a history beats an anonymous gist.
• Vendor what you depend on. Copy reviewed skills into the repository’s .agents/skills and update them through pull requests, so changes get reviewed like code.
• Pin when you link. If you symlink from a git checkout, check out a tag or commit rather than tracking a moving branch for skills you have not re-reviewed.
• Review diffs on update. git diff the skill folder after any update, whatever the installer.
• Disable instead of trusting. A [[skills.config]] entry with enabled = false turns off a skill you are unsure about without deleting it.
• Rotate if something leaked. If a skill ever ran with secrets exposed and you are not sure what it did, rotate the secrets. Deleting the skill does not undo a request it already made.

About the skills on this site

Every skill on codexskills.dev is plain text under the MIT license. The zip you download contains the skill folder, any references or scripts it uses, and a generated agents/openai.yaml with display metadata, so you can read all of it before installing. The same review advice applies here as anywhere: read before you install, especially anything in scripts/.

Related: how to install skills and the Security Audit collection.