Skip to main content
Codex runs shell commands, applies patches, and calls MCP tools on the developer machine. The TrustGuard Codex plugin puts your org’s policy check at each of those moments: Every decision lands in Activity with consumer_id prefixed codex:, so you also get a per-developer audit trail; start in Report policy mode to observe before enforcing. With allow_managed_hooks_only, developers cannot switch the hooks off. Under the hood the plugin uses Codex lifecycle hooks (not Codex External guardrails, which is a different extension point) calling POST /v1/evaluate. One org collector API key is shared across the company. Codex has no “import plugin from GitHub” marketplace flow like Cursor: you install from the repo (local) or IT deploys hooks + config (enterprise).

Coverage

Ask — Codex has no dialog: an ask gate is allowed, plus a warning injected as context the agent sees. Treat it as advisory here. Use it when your developers use Codex and you can deploy the hook scripts by MDM alongside the config. Not when your policy leans on ask gates — Codex does not honour them. Limits. Codex collapses ask to allow plus injected context, so treat ask as report-only here and use block where you need a stop. Config alone is not enough: without the bootstraps on disk the collector is inert. No redaction, no coverage of the model’s response, and tool declarations are not evaluated. Full comparison: Coverage.

Console setup

  1. Create a Codex collector (Catalog → IDE & coding agents).
  2. Mint a tgk_… API key on the Auth tab (shown once — store it).
  3. Assign a default policy on the Policies tab.

Local / pilot

make install-local:
  • Builds trustguard-codex and installs it under ~/.trustguard/bin
  • Copies the plugin to ~/.codex/plugins/trustguard
  • Writes ~/.codex/hooks.json with absolute paths to the bootstrap scripts
    (Codex runs hooks from the session cwd, so relative paths are unreliable)
Then write the API key config:
In Codex run /hooks, trust the TrustGuard definitions, and send a test prompt.

Enterprise

IT deploys more than the API key file. Codex does not pull hooks from a marketplace; managed hooks must already exist on disk.

1. Managed API key config

When this file includes api_key, that key, data_url, and fail_mode are locked (user ~/.trustguard/codex.json and env cannot override them). Soft prefs (timeout_ms, transform_action, events, consumer_id) still layer from the user file.

2. Enforce hooks (requirements.toml)

Example (see the full file in the plugin repo):
Source: docs/enterprise-requirements.toml in the plugin repo. Exact keys can vary by Codex version — confirm against Codex hooks docs. With allow_managed_hooks_only = true, developers cannot disable managed hooks from /hooks. Codex has no Ask permission dialog. A gate Ask (and transform-as-ask) becomes allow plus additionalContext: A TrustGuard policy needs your approval to continue. Use Block when you need a hard stop.

Verify

  1. In Codex run /hooks and confirm TrustGuard hooks are listed (and managed under enterprise policy).
  2. Send a test prompt.
  3. Confirm the event in TrustGuard Activity (consumer_id is typically codex:<user> or codex:<email> when the payload includes email).
Smoke-test the binary (optional):

What is evaluated

Attributes

  • attributes.collector.type = "ide"
  • attributes.source.application = "codex-plugin"
  • attributes.codex.event, cwd, model, turn
  • consumer_id prefixed codex: (email from payload when present, else configured / OS fallback)
Gate on tool.name from payload.params.name for MCP. Ask is context-only (see above).