Skip to content

Fix: Use configured model for API validation instead of hardcoded deprecated model#76

Open
theLightArchitect wants to merge 1 commit intoanthropics:mainfrom
theLightArchitect:fix/use-configured-model-for-validation
Open

Fix: Use configured model for API validation instead of hardcoded deprecated model#76
theLightArchitect wants to merge 1 commit intoanthropics:mainfrom
theLightArchitect:fix/use-configured-model-for-validation

Conversation

@theLightArchitect
Copy link

Summary

Fixes a two-layer bug where FindingsFilter silently disables Claude-based filtering due to a hardcoded deprecated model string.

Root cause analysis:

  1. validate_api_access() hardcoded "claude-3-5-haiku-20241022" instead of using self.model. When this deprecated model fails API validation, filtering silently disables with only a logger.warning() — no user-visible indication.

  2. initialize_findings_filter() did not pass the model parameter to FindingsFilter, so even when users configure CLAUDE_MODEL env var, it never reaches the ClaudeAPIClient used for filtering (though it correctly reaches SimpleClaudeRunner for the main audit).

Fix (3 source files + 1 test update + 1 new test file):

  • claude_api_client.py: Use self.model in validate_api_access() instead of hardcoded string
  • findings_filter.py: Add model parameter to FindingsFilter.__init__(), pass through to ClaudeAPIClient. Add GitHub Actions ::warning:: annotation when filtering disables (not just logger.warning)
  • github_action_audit.py: Pass model=DEFAULT_CLAUDE_MODEL to FindingsFilter initialization
  • test_helper_functions.py: Update existing test to expect the new model parameter
  • test_model_configuration.py: 8 new tests verifying model propagation and warning behavior

Why self.model instead of a new constant:

PR #73 proposes adding a VALIDATION_MODEL constant — but this creates another hardcoded model string that will eventually go stale (the same problem that caused this bug). Using self.model means validation always uses whatever model the user configured, with zero new constants to maintain.

Backward compatible: The CLAUDE_MODEL env var and DEFAULT_CLAUDE_MODEL constant continue to work as before. The only behavioral change is that validation now uses the configured model and surfaces a ::warning:: annotation on failure.

Test results: 181 tests pass (173 existing + 8 new), 0 failures.

Closes #69

Test plan

  • All 181 tests pass (python -m pytest claudecode/ -v)
  • New tests verify self.model is used (not hardcoded string)
  • New tests verify model flows from initialize_findings_filter()FindingsFilterClaudeAPIClient
  • New tests verify ::warning:: annotation on validation failure
  • Regression test confirms deprecated claude-3-5-haiku-20241022 is never used

…recated model

Fixes two layers of a bug where FindingsFilter silently disables Claude-based
filtering due to a deprecated model string:

1. validate_api_access() used hardcoded "claude-3-5-haiku-20241022" instead of
   self.model — now uses the model configured via CLAUDE_MODEL env var or default
2. initialize_findings_filter() did not pass model parameter to FindingsFilter —
   now passes DEFAULT_CLAUDE_MODEL through to ClaudeAPIClient
3. Added GitHub Actions ::warning:: annotation when filtering silently disables,
   so users get visible feedback (not just a logger.warning)

Includes 8 new tests verifying model propagation and warning behavior.

Closes anthropics#69

Co-Authored-By: Claude Opus 4.6 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Claude filtering silently disabled due to deprecated Haiku model in validate_api_access

1 participant