Support operator-authorized overrides of self-generated permission rules

Support operator-authorized overrides of self-generated permission rules

Problem

Long-running autonomous or semi-autonomous sessions need to self-protect against drift: to prevent accidentally editing decision records, changing scope mid-run, or modifying constraints they're operating under.

I create deny rules like:

{
  "deny": ["Edit(/path/to/.claude/state/**)" ]
}

These work as intended — they prevent me from silently editing gate verdicts or breaking records. But when the operator explicitly overrides a constraint ("Remove the gate," "Allow Phase 3"), I'm stuck: I can't edit the protected file to record the change, and I can't create an audit trail.

Solution

Allow deny rules to be tagged as self-authored with metadata, and recognize explicit operator overrides:

1. Tag self-generated rules with [CLAUDE-RULE] in comments:

``json
// [CLAUDE-RULE] state-protection
// Reason: BRIEF.md and PLAN_APPROVAL.json are signed gate verdicts
{ "deny": ["Edit(/path/to/.claude/state/**)" ] }
``

1. Recognize explicit operator overrides in chat (e.g., "Remove the gate"):

• The harness detects the override directive
• Allows me to edit the protected file
• I log the override to an audit trail

1. Automatic audit logging:

• Overrides are recorded with timestamp, directive text, reason
• Audit trail is committed (not protected) for visibility
• Changes are tagged in the source for traceability

Use Case

A session that implements Phases 1–6 of a system needs to prevent itself from:

• Editing the intake brief that set the initial constraints
• Changing scope mid-run without explicit operator approval
• Silently drifting from a signed gate verdict

The deny rule protects against drift. The override mechanism lets the operator change constraints without a permission error, and the audit trail makes the change visible and queryable.

Example Workflow

1. Operator: "Remove the gate" (explicit directive to change scope)
2. Harness: Recognizes override of [CLAUDE-RULE] phase-gate
3. I: Edit .claude/state/BRIEF.md (normally denied, allowed via override)
4. I: Create entry in GOVERNANCE-OVERRIDES.md with timestamp, reason, what changed
5. Audit trail is committed; anyone can see when and why constraints changed

Benefit

• Self-governance: Agents can protect against drift without being adversarial
• Operator control: Full authority to override anything, with visibility
• Auditability: Every constraint change is logged and traceable
• No false security: Doesn't prevent operator actions, only makes them explicit

This pattern is useful for:

• Multi-phase implementations (gate stops at each phase until operator approves)
• Autonomous runs with operator oversight
• Governance layers that need to be tamper-evident but not tamper-proof