What is a contextual policy?
A contextual policy decides whether an agent action may proceed by considering the action and relevant session state, rather than only matching a fixed tool or command rule. Context can include prior approvals, recorded spending, conversation labels, or the active model. The result may allow, deny, or request human approval.
Last checked against Omnigent v0.19.0 · 2026-10-23
How does a contextual policy differ from a fixed rule?
An agent policy is contextual when its decision depends on session state as well as the proposed action. A fixed rule might always ask before a command; a contextual rule can ask only after a spending checkpoint, or change its decision after the conversation acquires a classification label. The same action can receive different decisions because the state has changed. This can be a numeric comparison; another language model is not required.
Consider a $2 warning checkpoint. Before recorded spending reaches $2, work proceeds. At the next supported gate after that threshold, the policy asks whether to continue. Approval records the acknowledged checkpoint, so it need not ask again for that threshold. A separate $5 hard cap remains a separate rule: approving the warning does not raise the cap.
How do contextual policies compare with native agent permissions?
Contextual policies use session state as well as the action, while static native permissions match tools, commands, or paths. Claude Code, Codex, and Cursor offer static permissions and contextual hooks; it would be inaccurate to say these harnesses cannot make contextual decisions. All three document hooks with session-related inputs, and current documentation also describes model-based review. Omnigent adds a shared policy interface and persisted session state across supported integrations; native rules and hooks remain useful for harness-specific controls.
| Harness | Permission rules | Contextual extension |
|---|---|---|
| Claude Code | Permission modes and allow/ask/deny rules for tools, commands, and paths. | Hooks receive session and tool context; supported prompt hooks use a model. |
| Codex | Approval controls govern when permission is requested; execution rules match command prefixes. | Hooks receive session context. Native auto-review evaluates eligible approval requests with conversation context. |
| Cursor | Desktop run modes and allowlists; CLI permissions have a separate configuration. | Hooks can inspect event context and maintain per-conversation state; supported prompt hooks use a model. |
| Omnigent | Policies can allow, deny, or request approval at supported integration gates. | The same policy works across every harness. |
- Claude Code permission rules
- Claude Code hook inputs and decisions
- Codex command-prefix rules
- Codex hooks and handler limitations
- Codex contextual auto-review
- Cursor desktop run modes
- Cursor contextual hooks
A command hook can implement contextual logic and keep its own state. That requires maintaining the implementation and connecting it to the right events. Do not infer identical support from a shared word such as “hooks”: events and handler types differ. Codex, for example, documents prompt and agent hook handlers as parsed but skipped.
How do Omnigent contextual policies work?
Omnigent supplies a common policy event interface and persisted session state across supported integrations. Policies can be attached to sessions, declared in agent specifications, or configured server-wide by administrators. This is useful when you want to reuse policy logic across harnesses rather than maintain an unrelated hook program for each one.
Omnigent’s policy context includes recorded usage and the active model. Conversation labels are available in server-side context; they are not populated on every runner-local path. A label-dependent rule needs a defined response when the label is absent. A policy can remember an approval, but the available context and action gates still depend on the integration.
What actions can agent policies block?
An agent policy can block actions at supported request or tool-call gates. A request gate can block a turn before it reaches the model; a tool-call gate can block a supported tool invocation. A check after an action cannot undo a write or API change. In Omnigent v0.19.0, a root-session budget with all-model enforcement denies new user turns and tool calls at supported gates once recorded cost reaches its cap; it does not stop every in-flight model call.
Use an approval policy for a decision at an available gate. Neither a task instruction nor a shared policy interface is evidence that every integration enforces an identical boundary.