# CASAN Codex adoption template (Plan-20)

Drop `hooks.json` → `.codex/hooks.json` and merge `config.toml` into
`.codex/config.toml` in the target repo (the installer does this). It wires the
Codex lifecycle hooks to the CASAN agentic bridge via the thin renderer
`packages/casan-harness/adapters/codex/codex_hook.py`.

Important Codex-specific facts (Spike-20 §4.2):

- **Trust review is mandatory.** Codex loads project-local hooks only after the
  user accepts a trust prompt. Run `casan doctor --client codex` (or the bridge
  `doctor` op) to confirm the trust/onboarding state — it is never hidden from a
  member.
- **Tool hooks are a guardrail, not a complete boundary.** Hosted/specialized
  tools may fall outside hook coverage; a turn that uses an uncovered tool is
  **downgraded** (non-certified), not silently certified.
- **Token/cost source is not assumed.** Unless Codex supplies a stable usage
  source, H6 records the number as `null` with `telemetry_quality=partial` — it
  is never invented (Spike-20 X6).
- For enterprise enforcement, pin hooks via managed policy so a member cannot
  disable them and set `CASAN_AGENTIC_INTEGRATION_MODE=managed_hook` through the
  managed environment (not the committed config).

The command contract is stable (stdin JSON → exit 0 allow / exit 2 block); the
exact Codex payload key names are pinned during the Wave-3 payload spike, which
is why `codex_hook.py` reads several field aliases defensively.