This guide walks you through activating Canon Boundary Guard in a live Codex session, understanding what happens when the frame is adopted, and making your first request under the provenance classification posture. By the end you will have the plugin running, know how session behavior changes under the frame, and know what to do when context is compressed.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/XxYouDeaDPunKxX/canon-boundary-guard-codex/llms.txt
Use this file to discover all available pages before exploring further.
Activate and Explore the Frame
Install the plugin
If you have not already installed Canon Boundary Guard, add it to Codex now with the marketplace command:Then open
/plugins in Codex and enable Canon Boundary Guard. Full installation details, including hook setup, are covered on the Installation page.Start a new thread and activate the frame
Open a fresh Codex thread. Activate the plugin by telling Codex to use it for the session:You can also invoke the bundled skill directly by name:Both forms trigger the same behavior: Codex reads the full
SKILL.md operating specification before responding and adopts the provenance classification frame as its session-level posture.Observe how the frame is adopted
Canon Boundary Guard is adopted silently — Codex does not emit a confirmation message. Instead, before interpreting your first request, Codex scans the visible conversation prefix.If a leading user-role message begins with
AGENTS.md instructions for <path>, Codex classifies that entire block as L2A Codex instruction-chain prelude. It is not counted as your first request, and it is not treated as project content or ordinary chat. Any <environment_context>...</environment_context> block inside it is classified as runtime environment metadata.Your first real operator request is the first message after that prelude. From that point, the frame is active: non-L0 material will be tagged inline when it appears in output, provenance conflicts will be surfaced before writes, and the dossier protocol will engage when L1 or L3 material is promoted to persistent content.Make your first classification-aware request
Ask Codex to perform any task that touches project files — for example, editing a source file or updating documentation. Watch for inline provenance tags in Codex’s response.When Codex draws on material that is not verified project evidence, it will label it inline. For example:
- A version number from model memory and not from a lockfile will appear as
[L3] - A decision from the current conversation that has not been written to disk yet will appear as
[L1] - An operator-approved change staged for this turn will appear as
[L1A]
apply_patch, Write, or Edit tool call. That message confirms the compact classification frame was re-injected into the instruction stream at the write moment.What the Frame Does
The six provenance layers define how Codex classifies every piece of information it encounters during the session. The classification determines what can safely become persistent project content and what must be surfaced before writing.| Layer | Name | What it covers |
|---|---|---|
| L0 | EVIDENCE | Project files, git state, tests, schemas, lockfiles, diagnostics, verified command output, and verified tool output from the current task. |
| L1 | SHAPING | Conversation material not explicitly approved as a durable project decision. Present in context, not in the project. |
| L1A | AUTHORIZED DELTA | Material the operator has explicitly approved for persistence in the current turn. Becomes evidence only after it is written to a persistent artifact. |
| L2 | AGENT CONTROL | Instructions, steering, reminders, or constraints given to the agent to shape its behavior. Not project content. |
| L2A | CODEX INSTRUCTION CHAIN | AGENTS guidance and runtime instruction-chain material loaded by Codex. Governs Codex behavior at its scope. Not project content. |
| L3 | MODEL PRIOR | Unverified model memory, assumed conventions, generic best-practice claims, version references, or unstated framework behavior not grounded in local evidence. |
After Context Compaction
When Codex compresses long context — summarizing earlier conversation to stay within limits — the session frame may not survive intact in the compacted summary. If you notice that provenance tagging has stopped or that Codex is no longer surfacing classification conflicts, re-invoke the skill to re-establish the frame:The SKILL.md description explicitly calls for re-invocation after compaction. Treat it as a routine step when a session runs long.