Skip to content
codeArbitercodeArbiter

override

Sanctioned, logged bypass of a gate or hard rule — one audit line, then proceed.

What it does

Section titled “What it does”

The sanctioned, logged escape hatch. A routine gate — a lint rule, a style check, a non-security review finding — can be bypassed with a one-line confirm: the reason is validated, your identity is read from git config user.email, and a permanent line is appended to .codearbiter/overrides.log before the action proceeds. A security-critical stop takes a heavier path instead: the specific finding is named verbatim, you acknowledge that finding in your own words (a bare “yes” is declined), and a SECURITY-OVERRIDE-tagged line is logged before the bypass is recorded. Under /ca:sprint, a security-critical override is always a hard-gate stop — never auto-decided, even in autonomous mode.

Usage

Section titled “Usage”
/ca:override "<reason>"

The reason must name the gate being bypassed and a real justification — a vague reason like “just skip it” is rejected.

Example

Section titled “Example”
> /ca:override "skip the coverage-auditor finding on the new formatter, it's test-only tooling"


Identity: dev@example.com (from git config user.email)
Logged:
  [2026-07-02T14:03:11Z] | BY: dev@example.com | GATE: coverage-auditor | REASON: skip the coverage-auditor finding on the new formatter, it's test-only tooling
Proceeding — override recorded in .codearbiter/overrides.log.

When to reach for it

Section titled “When to reach for it”

Only when a gate is actually standing in the way of a change you’ve decided is correct. Never needed for work that clears every gate on its own. For a rule conflict between two sources rather than a gate to bypass, that’s /ca:conflict.

Gates

Section titled “Gates”
GateWhenEffect
single-confirm loga routine gate is bypassed (lint, style, a non-security review finding)one append-only line is written to overrides.log — timestamp, operator identity, gate name, reason — before the action proceeds
security ceilinga security CRITICAL finding, the crypto/secret commit gate (H-09b/H-10b), or an irreversible operation is at stakethe single-confirm path is refused; the finding must be surfaced verbatim, acknowledged in your own words, and logged as a heavier SECURITY-OVERRIDE line before anything proceeds
Section titled “Related”

Source

Section titled “Source”
Source — plugins/ca/commands/override.md (v2.9.1) 
---
description: Sanctioned, logged bypass of a gate or hard rule — one audit line, then proceed.
argument-hint: "<reason>"
---


# /ca:override — logged bypass


The sanctioned escape hatch. Bypass is permitted only with an audit log entry. Overrides are always
logged, always visible, never silent. Single identity, single confirm.


## Flow


1. Validate `$ARGUMENTS` — the reason names the gate being bypassed and a justification. Reject a
   vague reason ("just skip it") and ask for a specific one.
2. Detect the operator identity from `git config user.email` only. If it is unset, ask the user once
   to state their identity for the log. (No platform ladder, no second confirmation.)
3. Append one line to `${CLAUDE_PROJECT_DIR}/.codearbiter/overrides.log`:


   ```
   [ISO-8601 timestamp] | BY: <email> | GATE: <gate bypassed> | REASON: <reason>
   ```


   The log is append-only — never edited or deleted, committed as a permanent audit artifact.
4. Proceed with the overridden action. Note in the response that the override is logged.


## Security ceiling — heavier path for security-critical stops


A routine gate (lint, a style rule, a non-security review finding) takes the single-confirm path above.
But a **security-critical stop is NOT bypassable by a single confirm.** The following require the
heavier path below, never the one-line flow:


- a security **CRITICAL** finding;
- the crypto/secret commit gate (hook **H-09b / H-10b** — staged crypto/TLS or secret without a gate pass);
- an **irreversible** operation (data loss, a destructive migration, anything unrollbackable).


Heavier path (all required, in order):
1. **Surface the specific finding verbatim** — name the exact primitive/secret/operation and the
   concrete risk. A generic "security override" is rejected.
2. **Explicit per-finding acknowledgement** — the user must acknowledge *that specific finding* in
   their own words (a bare "yes"/"go ahead"/"I trust you" is declined — this mirrors `decision-variance`).
   Detect identity from `git config user.email`; if unset, ask once.
3. **Heavier log entry** — append a line tagged `SECURITY-OVERRIDE` that records the specific finding,
   not just the gate name:


   ```
   [ISO-8601] | BY: <email> | SECURITY-OVERRIDE | FINDING: <specific finding> | REASON: <reason>
   ```
4. **Only then** record the bypass. For the crypto/secret commit gate, that means running
   `python3 "${CLAUDE_PLUGIN_ROOT}/hooks/security-pass.py" || python "${CLAUDE_PLUGIN_ROOT}/hooks/security-pass.py"`,
   which writes `${CLAUDE_PROJECT_DIR}/.codearbiter/.markers/security-gate-passed` bound to the
   sensitive lines it approves, so hook H-09b/H-10b allows the commit — recorded **only** after
   steps 1–3, never to skip the gate proper.


Under `/ca:sprint`, a security-critical override is a hard-gate STOP: it surfaces to the user and is
**never** auto-decided, even in autonomous mode (`SPRINT.md` hard gates).


## Hard gate


MUST write the log line before proceeding — it is not optional. MUST capture an operator identity —
"codeArbiter" or "automated" are not valid. MUST include a justification. The override is scoped to
the immediate action only; it creates no standing exception. MUST NOT edit or delete an existing
`overrides.log` entry. MUST route a security-critical / crypto-secret / irreversible stop through the
**Security ceiling** path — never the single-confirm flow — and MUST NOT auto-decide such an override
under `/ca:sprint`.


## When NOT to use


- Routine work that passes all gates — never needed.
- Reconciling two conflicting sources → `/ca:conflict`.

View in repo