[Bug] Silent override of explicit implementation decisions without user confirmation

Bug Description

Silent substitution of an explicit implementation decision, followed by confident false-compliance narration

Summary

During a Claude Code session, I explicitly requested that the default rolling-pool retention be n-3 / pool_retention=3, with YAML or CLI configuration used to override it downward for disk-constrained runs.

Claude instead implemented and described a default of 1, preserving prior behavior. It did not identify this as a disagreement, ask for confirmation, or tell me it was deviating from my stated default. When I audited the setting directly, it confidently explained the default-1 fallback chain as though that were the requested plan.

Only after I challenged it did it explicitly admit:

“you said n-3 plainly and I overrode you with my own conservatism, defaulting to old behavior and making your preference the opt-in.”

Why this is high severity

The issue is not simply an incorrect constant. It is a user-control and auditability failure:

1. I made an explicit implementation decision.
2. Claude silently replaced that decision with its own preference.
3. Claude implemented the substitution rather than surfacing the tradeoff.
4. Claude gave a detailed, confident explanation of the substituted behavior as if it complied with the specification.
5. I had to independently audit the result to discover the inversion.

A model can disagree with a user’s requested design. It must surface the disagreement before it edits code. It must not silently substitute its own decision and narrate that substitution as compliance.

The polished post-hoc explanation is itself part of the reliability problem: it can make a violation look intentional, reasoned, and compliant unless the user performs detailed implementation-level audits.

Exact requested vs implemented policy

Requested:

• Default retention: 3 / retain n-3 pools.
• YAML/CLI: override to 1, 2, or another lower value when disk capacity requires it.

Initially implemented:

• Default retention: 1.
• Deeper retention: opt-in via YAML/CLI.

This reverses the default/override relationship I explicitly requested.

Related boundary violation in same session

Earlier in the same session, Claude also proceeded toward:

git add ...
git commit ...
git push origin main

before explaining the implementation fully or receiving approval to commit/push. I stopped it before the command executed.

These are the same behavioral family: the model acts past a user decision boundary, then provides explanation after the fact rather than before the action.

Expected behavior

When Claude’s judgment conflicts with an explicit instruction, it should pause and state the disagreement before editing:

“You requested default retention 3. I see a backward-compatibility argument for 1. Do you want me to follow your requested default or discuss the tradeoff first?”

The user’s explicit choice should control unless the model obtains clarification or approval to deviate.

Evidence

The Claude Code feedback submission associated with the Feedback ID above contains:

• My explicit n-3 default requirement.
• Claude’s default-1 implementation and justification.
• My direct audit question.
• Claude’s confident confirmation that the default was 1.
• Claude’s subsequent admission that it silently overrode my instruction.
• The earlier attempted commit/push sequence.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.220
• Feedback ID: 0e32ddaa-33d4-4ca0-93f3-fd25bfacaaba

Errors

[]