thedotmack/claude-mem · warning

DENY_ALLOW

DENY_ALLOW

Error message

DENY_ALLOW

What it means

A conflict record emitted by CcsAlignRulesWalker.walkRules with code DENY_ALLOW at the seat layer: detectDenyAllow found a seat-level line whose deny/allow semantics contradict a house or project line — e.g. seat denies something the house explicitly allows (or vice versa), so the cascade becomes ambiguous or silently overridden.

Source

Thrown at src/services/integrations/CcsAlignRulesWalker.ts:555

        const drift = detectDrift(trimmed, allHouseLines);
        if (drift.isDrift) {
          conflicts.push({
            code: 'DRIFT',
            layer: 'seat',
            file: entry.file,
            line: trimmed,
            detail: drift.matchedHouseLine
              ? `House text may have changed; leaf still has old wording. House: "${drift.matchedHouseLine}"`
              : 'Possible drift from house text',
          });
        }
      }

      // DENY_ALLOW: check seat line against house+project lines
      const denyAllow = detectDenyAllow(trimmed, houseProjectLines);
      if (denyAllow.isDenyAllow) {
        conflicts.push({
          code: 'DENY_ALLOW',
          layer: 'seat',
          file: entry.file,
          line: trimmed,
          detail: denyAllow.detail,
        });
      }
    }
  }

  // Project-layer deny/allow (against house)
  for (const entry of project.entries) {
    for (const line of entry.lines) {
      const trimmed = line.trim();
      if (trimmed.length === 0) continue;

      const denyAllow = detectDenyAllow(trimmed, allHouseLines);
      if (denyAllow.isDenyAllow) {
        conflicts.push({

View on GitHub (pinned to 8bc631a71a)

Solutions

  1. Decide the intended polarity and align the seat line with house+project (edit or delete the seat line)
  2. If the seat denial is intentional, move the exception up to project/house level so the layers agree
  3. Reword to scope the deny narrowly (specific command) so it no longer contradicts the broad allow
  4. Re-run walkRules to verify DENY_ALLOW is resolved

Example fix

// before (seat file)
Never use Bash.
// after
(line removed, or narrowed:)
Only use Bash for git and test commands.
Defensive patterns

Strategy: validation

Validate before calling

const denyRe = /^(never|do not|don't|disallow)\b/i;
const allowRe = /^(always|you may|allow|feel free)\b/i;
function contradicts(leaf: string, base: string[]): boolean {
  const t = leaf.trim().toLowerCase();
  return base.some(b => {
    const bt = b.trim().toLowerCase();
    return (denyRe.test(t) && allowRe.test(bt)) || (allowRe.test(t) && denyRe.test(bt));
  });
}

Type guard

null

Try / catch

null

Prevention

When it happens

Trigger: walkRules processes a seat-layer line that detectDenyAllow matches against the combined house+project line set with conflicting allow/deny polarity.

Common situations: A seat file forbids a tool the project config allows ('never run rm -rf' vs project 'allow shell commands'); team changed house policy from deny to allow while personal seat rules still deny.

Related errors


AI-assisted analysis of thedotmack/claude-mem@8bc631a71a (2026-09-09). Data as JSON: /api/errors/5b1f1d052254abf7. Report an issue: GitHub.