Feature Request: Mark code sections as 'do not modify' to prevent unnecessary changes

[valllabh]

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When working on complex applications, Claude Code sometimes modifies working code (functions, classes, configuration, business logic) while attempting to fix unrelated issues. This leads to regressions, wasted debugging time, and reduced trust in the tool.

Real-World Examples Where This Problem Occurs

Example 1: Model Configuration Changes While debugging tool call handling logic in an AI agent application, Claude Code repeatedly assumed the model didn't support tool calls and changed the working model configuration from a custom setup to Anthropic's Opus. The actual issue was in the parsing logic, not the model selection.

Example 2: Authentication Logic Modification While fixing a UI button styling issue, Claude Code refactored a working authentication function, changing the token validation logic "for consistency." This broke the auth flow and required reverting changes that had nothing to do with the original styling bug.

Example 3: Database Query Rewrite While adding a new field to a form, Claude Code decided to "optimize" a working database query in an unrelated file, changing a complex JOIN that had been carefully tuned for performance. The optimization actually degraded performance and broke edge cases.

Example 4: API Integration Changes While fixing error handling in one endpoint, Claude Code modified the working request/response formatting in other API endpoints "to maintain consistency," breaking integrations with third-party services.

Example 5: State Management Refactoring While debugging a specific React component's rendering issue, Claude Code refactored the entire Redux store structure "to follow best practices," requiring extensive testing and reverting of working state management code.

Example 6: Testing Utilities Modification While adding a new test case, Claude Code rewrote working test helper functions and mock utilities "for clarity," which broke dozens of existing tests that depended on the original implementation.

Example 7: Business Logic "Simplification" While fixing a validation bug, Claude Code simplified complex business logic in a pricing calculation function, removing edge case handling that was actually required for specific customer scenarios.

Example 8: Class Hierarchy Changes While fixing a method in a child class, Claude Code refactored the parent class inheritance structure "for better design," breaking multiple other child classes that relied on the existing hierarchy.

Common Pattern

The pattern is clear: Claude Code often makes assumptions about what's "wrong" or "inconsistent" in working code while attempting to fix an unrelated issue. Users need a way to mark stable, tested, working code as "do not modify" to prevent these productivity-killing regressions.

Proposed Solution

Add a mechanism to mark portions of code (functions, classes, config blocks, entire files) as "finalized" or "locked" so Claude Code knows not to modify them while working on other issues.

Potential implementations:

1. Special comments: Mark sections with // @claude-lock-start and // @claude-lock-end

   // @claude-lock-start
   function authenticateUser(token) {
     // This is working - don't modify!
     return validateToken(token);
   }
   // @claude-lock-end
   

2. Inline markers: Single-function or single-class protection

   # @claude-locked
   class PaymentProcessor:
       # This payment logic is tested and certified - do not modify
       def process_payment(self, amount):
           ...
   

3. Configuration file: .claudeignore or .claude/locked.json to specify protected files/sections

   {
     "locked": [
       "src/auth/**",
       "lib/payment-processor.ts:PaymentProcessor",
       "config/models.yaml:15-42"
     ]
   }
   

4. Session commands: Runtime commands to mark/unmark sections during an active session

   /lock src/auth/validate.ts:authenticateUser
   /lock config/database.js:45-67
   /unlock src/utils/helpers.ts
   

5. Integration with existing markers: Extend TODO/NOTE comment patterns

   // LOCKED: Working database connection - do not modify
   const dbConfig = { ... }
   

Alternative Solutions

Current workarounds:

• Repeatedly explaining to Claude which parts of the code are working correctly
• Manually reverting unwanted changes after each iteration
• Breaking work into smaller, isolated sessions to limit the scope of potential changes
• Creating detailed prompts like "only modify the button styling, do NOT touch any other code"
• Reviewing every single change Claude makes before accepting

Other tools' approaches:

• Some IDEs have "read-only" regions for generated code
• Git has assume-unchanged for files, though that's version control specific
• Some code generation tools use marker comments to designate protected regions
• Tools like Copilot work on smaller scopes, reducing this issue

None of these directly solve the problem within Claude Code's interactive workflow where changes can span multiple files and components.

Priority

High - Significant impact on productivity

When working on complex systems, the time spent reverting and re-explaining correct code significantly impacts development velocity, trust in the tool, and overall developer experience. This issue becomes exponentially worse as codebase complexity increases.

Feature Category

Configuration and settings (or potentially CLI commands and flags if implemented as session commands)

Could also involve Interactive mode (TUI) if implementing visual indicators for locked sections.

Use Case Examples

Use Case 1: AI Agent Development

1. I'm working on an AI agent application with configured LLM model and tool call handling
2. I discover a bug in how tool call responses are being parsed
3. I mark the model configuration as locked: // @claude-lock around the config block
4. I ask Claude Code to fix the parsing logic
5. Claude Code fixes the parsing bug WITHOUT touching the model configuration
6. I get a clean, focused fix without regressions

Use Case 2: Full-Stack Bug Fix

1. I'm fixing a frontend validation bug in a React form
2. The backend API endpoints are working perfectly and have been tested
3. I lock the API route handlers and database query functions
4. I ask Claude to fix the frontend validation
5. Claude fixes the validation WITHOUT refactoring my working backend code
6. My API integrations remain stable and unchanged

Use Case 3: Incremental Refactoring

1. I'm refactoring a large codebase module by module
2. Module A is refactored, tested, and deployed to production
3. I lock Module A while working on Module B
4. When fixing issues in Module B, Claude respects the lock on Module A
5. I can confidently refactor knowing stable modules won't be touched

Use Case 4: Third-Party Integration Protection

1. I have complex OAuth integration code that works with specific provider quirks
2. I'm adding a new feature to my app
3. I lock the OAuth integration code that took weeks to get right
4. Claude implements the new feature WITHOUT "improving" the working OAuth code
5. My authentication flow remains stable

Use Case 5: Performance-Critical Code

1. I have database queries optimized for specific performance requirements
2. I'm adding a new feature that uses different queries
3. I lock the optimized queries to prevent "helpful" refactoring
4. Claude adds the new feature WITHOUT changing performance-tuned code
5. My app maintains its performance SLAs

Use Case 6: Team Collaboration

1. A teammate wrote complex business logic that's tested and approved
2. I'm fixing a bug in my code that interacts with their code
3. I lock their tested functions before asking Claude for help
4. Claude fixes my bug WITHOUT modifying my teammate's working code
5. I avoid creating conflicts and regressions in team code

Additional Context

Benefits:

• Prevents regressions: Working code (functions, classes, config) stays working
• Reduces iteration cycles: Less back-and-forth fixing unintended changes
• Enables incremental debugging: Focus on the actual problem without side effects
• Better for complex systems: Allows declaring stable components in large codebases
• Builds trust: Users can confidently work on complex projects knowing certain parts are protected
• Supports team workflows: Protect code written by other team members
• Production safety: Mark production-critical code as untouchable during development
• Reduces cognitive load: Don't have to constantly police Claude's changes

Technical Considerations:

• Locked sections should be clearly visible in the TUI/interface
• Should support granularity from entire files down to specific functions/classes
• Should persist across sessions (via config file) or be session-specific (via commands)
• Should have easy lock/unlock toggle commands
• Could show warnings if Claude "wants" to modify locked code with explanation of why

Visual Mockup Idea:

📁 src/
  📄 auth.ts ━━ 🔒 LOCKED
  📄 database.ts
    ├─ function connectDB() ━━ 🔒 LOCKED (lines 15-42)
    └─ function executeQuery()

This feature would be especially valuable for production codebases where stability of certain components is critical while iterating on others. It addresses a fundamental tension in AI-assisted development: the balance between helpful suggestions and unwanted modifications.