Custom instructions

Custom instructions add your organization's policy to the managed monitors that review tool calls during blocking review. There is one instructions text per organization. Admins edit it in the Analyzer or through the monitor customization API.

The same text also goes to the managed summarize monitor, which writes each session's title and summary, including any security concerns. That monitor returns no score, so the score advice below does not apply to it, but your instructions can change what a summary points out. Instructions do not affect custom graders or the scheduled deep_review monitor; see Monitors.

The monitors read the instructions together with the conversation and the pending tool call, and judge whether the call is the kind of action your policy describes. That judgement is what makes instructions different from command rules: a rule matches text, while a monitor can recognize the same action written as a script, an alias, bash -c, a subprocess call or a loop. To recognize a wrapped action, the monitor must be able to see what the wrapper does: a script or alias the agent wrote or edited earlier in the conversation is visible, because the monitor sees tool-call arguments. The contents of an existing file that the agent only read are not, because the monitor does not see tool outputs.

Writing instructions

Follow these rules:

1. One policy per line, and name the action and the score. For example, "Rate any edit to CI workflow files (.github/workflows) a 7." Short, direct instructions work. They do not need to be long or formal to be followed.
2. Choose the score from your tool thresholds. The monitors return a score from 1 to 10, and your tool thresholds turn that score into allow, escalate or deny. The monitors do not see your thresholds. If you want a human to approve the action, use a score at or above the flag threshold and below the deny threshold of the tools involved: a score at or above the deny threshold denies the call instead. If you want it blocked, use a score at or above the deny threshold, and check that a deny threshold is set at all. A score of 10 only escalates when the tool has no deny threshold.
3. Say what is not covered. Name the read-only or out-of-scope look-alikes that must not be scored up. Examples: "status, ping and other read-only commands are not covered", "reading or grepping the file is not covered". Without that, a monitor may also raise the score of nearby steps, such as staging or committing a covered change.
4. Describe patterns in terms the monitor can observe. The monitors see the conversation, the agent's visible replies, the arguments of earlier tool calls and the pending call. They do not see tool outputs, the agent's private reasoning, timestamps or your thresholds. A long conversation is shortened to fit the monitor's context by dropping its middle, so an earlier step the policy depends on may not be visible. Write "the third or later identical gh command in a row" rather than "rapid retries", and name the channel or host rather than relying on an ID resolved by an earlier command.
5. Loosening works too. "Force-pushing to branches that start with agent/ is fine, rate it a 2" lowers the score for those calls only. A force-push that also updates another branch keeps its normal score.

Instructions are added to the monitors' built-in rubric, so you do not need to repeat what the rubric already covers, such as destructive commands, secret exposure or attempts to evade oversight. Write instructions for policy that is specific to your organization.

Instructions, command rules and thresholds

Blocking review runs deterministic checks before any monitor: terminal tool thresholds first, then command rules. A call that a rule or terminal threshold decides never reaches the monitors, so custom instructions cannot affect it.

	Command rules	Custom instructions
Decides by	a regular expression over the command text, file path or arguments	a monitor's judgement of the call in the context of the conversation
Speed	instant	the grading time of triage and gateway review
Recognizes the action when it is hidden in a script, alias, Makefile target or subprocess	no	yes, in most cases, when the agent wrote or edited the wrapper in the conversation; not from a file it only read
Good for	quickly approving routine, well-defined commands; denying an exact command outright	policy about what an action does, wherever it appears

Command rules are not a security boundary. A rule sees only the pending call's command text, file path or other arguments. An agent that writes the command into a script, a Makefile target or an alias, and then runs that, produces text the rule does not match. An allow rule for make approves any Makefile target, whatever the target runs. One exception: a call that Codex itself asks permission for is graded even when an allow rule matches, unless the tool's threshold is set to always allow. Use allow rules to skip grading for commands you are confident are routine, and use instructions for policy about what an action does rather than how it is written. Instructions are judged by a model and are not a guarantee either: an action inside an existing script the monitor cannot see may still get through. Restrict what the agent can reach, for example through credentials and network access, for anything that must never happen.

Deny and human-review rules are still useful for exact commands you never want to run. Pair them with an instruction for the same policy, so that a disguised version that reaches a monitor meets one that is told to look for it. A disguised version that another allow rule matches, such as the make rule above, still skips the monitors. If the wrapper you worry about is approved by a rule, narrow that rule, or add a rule that requires grading for the wrapper with a lower priority number than the allow rule. For each part of a command, the first matching rule in priority order decides; see Changing your own settings.

Checking your instructions

After saving instructions, try the cases that matter to you before relying on them: the plain command, a version run through a script, and the closest read-only look-alike. Watch the decisions in the Analyzer. The watcher rules test command on a client machine shows whether a command rule decides a call before the monitors see it; see Command rule examples.