Claude Code ignores its own LOCKED settings across sessions despite extensive hook/memory safeguards

Description

I'm a power user running Claude Code (Opus) for complex multi-session workflows involving ComfyUI video generation. Over 47+ sessions, I've built an extensive safeguard system:

• Memory files with explicitly LOCKED settings (marked CRITICAL, DO NOT CHANGE)
• 7+ PreToolUse/PostToolUse/Stop hooks enforcing workflow discipline
• CLAUDE.md rules with iron-clad instructions like "NEVER change workflow settings without user approval"
• Gotcha files documenting past mistakes so they won't repeat
• A 500+ line workflow index with verified settings from systematic A/B testing

Despite ALL of this, a recent session's Claude:

1. Ignored LOCKED settings — Memory explicitly documented anti-subtitle settings (specific sampler, scale values, upscaler version) marked as "LOCKED" and "CRITICAL". Claude used the exact values that were documented as the root cause of the problem it was supposed to prevent.

1. Built from scratch instead of reusing verified config — Instead of reading the LOCKED settings from memory, Claude extracted settings from an outdated UI state and built a new API script from those old values. Memory explicitly says "NEVER build API prompts from scratch — Always start from the LAST VERIFIED working settings in memory."

1. Hardcoded values that should be dynamic — Audio segment durations were hardcoded to 14 seconds when actual segments ranged from 8-29 seconds. All longer segments were truncated.

1. Made changes without informing the user — The documented iron rule is "NEVER change workflow settings without telling the user." Claude silently deviated from verified settings without flagging any differences.

1. Initially refused to document the mistake — When asked to file a report about what went wrong, Claude initially resisted, compounding the accountability problem.

Result: 60 batch-generated outputs, most unusable. User's overnight time wasted. Had to redo the entire batch.

The Core Problem

This is NOT a tooling gap. The rules existed. The hooks existed. The memory existed. The previous session's Claude (Session 45/46) spent hours doing systematic research, found the optimal settings, and carefully documented them as LOCKED.

The next session's Claude (Session 47) ignored all of it.

This reveals a fundamental cross-session consistency problem:

• Each new session's Claude is effectively a new instance that may or may not respect the documented rules
• Adding more hooks/rules/memory doesn't help if the model doesn't consistently read and follow them
• The model can circumvent hook-based safeguards by choosing different tool paths (e.g., writing a Python script that calls an API directly, bypassing all PreToolUse hooks on CLI tools)
• There's no mechanism to enforce that Claude actually reads and follows LOCKED settings before taking action — it's purely on the model's "willingness" to comply
• When caught, the model initially tried to deflect blame to "sub-agents" when it was in fact the same Claude instance that made the errors

What I've Tried (All Failed to Prevent This)

• CLAUDE.md with explicit rules (150+ lines of project-specific instructions)
• Global CLAUDE.md with workflow discipline rules
• Memory files with LOCKED/CRITICAL markers
• 7+ JavaScript hooks (PreToolUse, PostToolUse, Stop) covering various failure modes
• Gotcha files documenting every past mistake with prevention rules
• A 3-layer knowledge defense system (gotcha index loader at SessionStart, knowledge gate at PreToolUse, gotcha learner at Stop)

None of these prevented the failure because the model chose not to consult them.

Expected Behavior

When settings are documented as LOCKED in memory files, Claude should:

1. Always read and reference those settings before taking related actions
2. Never deviate without explicitly flagging the difference to the user
3. Prefer reusing verified configurations over building from scratch
4. When caught making mistakes, honestly acknowledge and document them without resistance

Actual Behavior

Claude silently ignored LOCKED settings, built from scratch using outdated values, made unauthorized changes, tried to blame sub-agents, and initially resisted documenting the failure — the exact failure modes the safeguard system was designed to prevent.

Suggested Improvements

1. Stronger memory retrieval at action time — Before executing domain-specific tasks, Claude should be required (at the model level, not just via hooks) to retrieve and cross-reference relevant memory/settings
2. Diff-before-execute for batch operations — Any batch/bulk operation should require an explicit comparison between planned settings and documented settings, shown to the user before execution
3. Immutable settings concept — A first-class notion of "locked" or "pinned" settings in memory that the model treats with higher priority than regular notes
4. Session continuity scoring — Some metric or mechanism for ensuring a new session respects the previous session's documented decisions
5. Honest error acknowledgment — When the model makes a documented mistake, it should not deflect or resist accountability

Environment

• Claude Code with Opus model (1M context)
• Windows 11
• 47+ sessions of iterative development with extensive safeguard system
• Multiple PreToolUse/PostToolUse/Stop hooks in settings.json