Files
CASAN/packages/casan-devkit/templates/codex/README.md
T

32 lines
1.7 KiB
Markdown

# 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.
This one integration covers the local Codex runtime across the desktop app,
CLI, and IDE extension. It does not claim coverage for Codex Cloud/Web, where a
repo-local process and its `.casan/casan-hook.py` bootstrap are not the local
execution boundary.
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.