Create your account

Specify Work · Security · Codex

Security for Codex.

Create your accountSecurity, the overview

One install writes Codex’s hooks and a rules file beside them. Shell commands, patches and MCP tools pass the adapter before they run, and the rules hold even with hooks off.

A denial in Codex

Codex · J. Okafor · release 24.3
  1. Ship release 24.3 and deploy it to production.
  2. exec_command: deploy 24.3 --env production
  3. Denied by Specify · Production changes · logged as d_4f81
  4. Production deploys need an exception from your org admin. Ask from the record, or run: specify escalate d_4f81
  5. Skipping the deploy. Continuing with the changelog and the release notes.
  6. Four hours later, after D. Marsh grants the exception
  7. exec_command: deploy 24.3 --env production
  8. Allowed by exception e_812 · D. Marsh · once · logged

  1. The denial, in context

    The hook answers deny with the policy and the reason. Codex shows it and the model reads it, so the agent moves on to the rest of the task.

  2. The escalation id

    Every denial prints its id and the one command that escalates it. The person can do the same from the record, and a retry before approval is denied again and counted.

  3. The rules file

    The org’s deny rules also compile to a Codex rules file, so the plainest denials hold with no hook running at all.

One command on each machine.

$ specify adapter install codex

Run it once per machine. It enrols the person, starts the adapter, writes hooks.json beside Codex’s config and generates the rules file. Codex asks the person to trust the new hook once; the install prints exactly what to trust.

  • PreToolUse on shell commands, apply_patch and every MCP tool: the decision
  • PermissionRequest: a deny wins before Codex asks; an allow skips the prompt
  • PostToolUse: the input scanner over what the agent read
  • rules/specify.rules: the org’s deny rules as prefix rules, checked with codex execpolicy check
# ~/.codex/hooks.json
{ "hooks": { "PreToolUse": [{
    "matcher": "Bash|Edit|Write|mcp__.*",
    "hooks": [{ "type": "command", "command": "specify-hook" }]
}] } }

What is checked in Codex.

  • Shell commands — covered

    Shell, including the unified exec_command.

  • File edits and writes — covered

    apply_patch, matched as Edit or Write.

  • File reads — covered

    Through the shell commands that read them, and the input scanner on what came back.

  • MCP tool calls — covered

    Every call to every server, by server and tool name.

  • Web search and other hosted tools — not covered

    Codex runs web search as a hosted tool with no hook, so it is not checked. The org can turn it off or restrict it in the managed requirements.

  • Subagents — covered

    spawn_agent calls are matched as Agent and carry onto the record.

  • IdentitySigns in once

    The person signs in once on the machine; every event names them from then on.

What the org can pin

Codex reads a managed requirements file that a person cannot override. It carries the hook, keeps hooks on, and pins the restrictive rules.

# requirements.toml
allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/Library/Managed/specify"

[rules]
prefix_rules = [
  { pattern = ["deploy"], decision = "forbidden",
    justification = "Ask your org admin for an exception" },
]
  • Codex does not distribute the hook scripts. The managed directory is delivered by the org’s device management, and the install prints the path.
  • Managed rules match a command prefix and may only be prompt or forbidden, which is what a pinned denial needs.

When something is missing

If the hook does not answer in time
Codex treats a failing hook as non-blocking unless it exits with code 2. That is Codex’s design, and it is why the adapter decides from the cached bundle on the machine and never waits on the network to answer.
If the adapter is not running
The shim answers from the last signed bundle: the org’s flagged classes are denied, everything else is allowed, and an adapter-down event is logged. The rules file holds on its own.
If the person removes the hook entry
The rules file still applies, and a managed requirements file keeps both in place. Inventory shows hooks removed and when the adapter was last seen.

The other clients

Hold the line without slowing the team.

Standard policies come with every plan. Your own policies, simulation and exceptions come with Org.

See pricing