# CASAN Codex adoption template (Plan-20)

`casan init --client codex` merges `hooks.json` into `.codex/hooks.json`. Each
handler calls `.casan/casan-hook.py`, which resolves and verifies the pinned
global harness before dispatching the Codex adapter. No custom `[casan]` TOML
keys are required.

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 shape follows current Codex hooks: nested command handlers,
`timeout` in seconds, `continue`/`stopReason` for turn events, and exit 2 for a
denied `PreToolUse`. The adapter reads documented fields plus defensive aliases.