Module policy 

Policy capabilities: rules that narrow what an agent may do.

A policy is a list of rules, each with an effect, deny or ask, and exactly one subject: a command prefix, file paths an agent may not read, file paths it may not edit, or an MCP tool. There is no allow effect. A policy can come from anyone’s repository or pack, and one that could grant permissions could quietly widen what an agent may do in every project that installs it; a policy that can only take permissions away can at worst be too strict, and too strict is visible.

The subjects are deliberately the intersection of what harnesses can match: commands by prefix and paths by glob. A richer rule would compile into something that means less than it says.

Every harness declares, per effect and subject, how it enforces such a rule, in the same full / partial / unsupported terms the hooks specification uses. Until a harness compiles policies, every row is unsupported, and installing a policy for it is refused rather than reported as installed.

Structs

PolicyConfig

The [policy] section of a type = "policy" manifest.

PolicyCoverageEntry

How one harness enforces one kind of rule.

PolicyRule

One [[policy.rules]] entry, as written.

RuleVerdict

One rule’s verdict on one harness.

Enums

PolicyEffect

What a matching rule does to the call.

PolicySubject

A rule’s subject, once validated.

PolicySubjectKind

The kind of thing a rule matches.

Constants

RULES_FILE_HEADER

The first line of a rules file Tuff writes.

Functions

enforcement

Split a policy’s rules by whether a harness enforces them: the zero-based positions of the rules its matrix covers full or partial, and a record of each rule it covers unsupported, for the lockfile when the policy is installed with --accept-unenforced (RFC-107 D6).

is_codex_config

Whether a native permissions file is a Codex config.toml, where an MCP tool rule sits on the server’s [mcp_servers.<id>] table.

is_opencode_config

Whether a native permissions file is an OpenCode config file, whose permission object maps permission names to actions, or to patterns and actions, and whose order OpenCode reads as precedence.

is_rules_file

Whether a native permissions file is a rules file, one compiled rule per line, such as Codex’s .codex/rules/tuff.rules, rather than a JSON settings file.

managed_permission_status

Whether a recorded rule is still in its list: clean when it is, missing when the rule or the file is gone, modified when the file is no longer valid JSON.

merge_permissions

Add and remove native permission rules in a harness settings file, given the bytes it holds now, and return the bytes it should hold next.

no_gaps

A RuleGap for a harness whose matrix rows apply to every rule.

not_implemented_matrix

The matrix of a harness Tuff does not compile policies for: every effect and subject unsupported, said plainly.

permission_location

Where tuff check reports a compiled rule that is missing: the file for a rules file, the permission for an OpenCode config, the server setting for a Codex config, and the list for a JSON settings file.

remove_permissions

Take recorded permission rules back out of their settings files.

validate_policy

Refuse a policy that could not be enforced as written anywhere: no rules, or a rule with no subject, two subjects, an allow effect, or a malformed pattern.

verdicts

Look up every rule in a harness’s matrix. A matrix missing a row for a rule’s effect and subject is treated as unsupported, never as enforced, and so is a rule gap names a reason for.

Type Aliases

RuleGap

Why a harness cannot enforce one rule even though its matrix row for the rule’s effect and subject says it can, such as a pattern its native setting has no form for; None when the row applies.