Summary
ClaudeAPIClient.validate_api_access() hardcodes claude-3-5-haiku-20241022, which Anthropic retired on 2026-02-19. Every run now fails that health check, and FindingsFilter reacts by disabling Claude-based false-positive filtering entirely. The action still reports success, so the degradation is silent.
Where
claudecode/claude_api_client.py (currently on main, 0c6a49f1fa56a1d472575da86a94dbc1edb78eda):
def validate_api_access(self) -> Tuple[bool, str]:
try:
# Simple test call to verify API access
self.client.messages.create(
model="claude-3-5-haiku-20241022",
max_tokens=10,
...
claudecode/findings_filter.py:
valid, error = self.claude_client.validate_api_access()
if not valid:
logger.warning(f"Claude API validation failed: {error}")
self.claude_client = None
self.use_claude_filtering = False
Impact
- False-positive filtering is off for every user of the action since 2026-02-19, degrading signal quality without any visible failure (the workflow step still passes).
- Each run emits a failed
not_found_error request, so Anthropic sends users retired-model warning emails naming their API key. That is how we found this: three failed requests on a given day matched exactly three Security Lane runs.
Note the claude-model input does not help, since it sets self.model for analysis but not this hardcoded health-check model.
Suggested fix
Use self.model for the validation call rather than a hardcoded id, so it follows the claude-model input and cannot rot again:
self.client.messages.create(
model=self.model,
max_tokens=10,
...
Alternatively, pin the health check to a current model (claude-haiku-4-5), though using self.model avoids a repeat of this in the future. It may also be worth making the filtering-disabled path louder than logger.warning, since users cannot tell filtering silently stopped.
Environment
- Action pinned to
0c6a49f1fa56a1d472575da86a94dbc1edb78eda (also current main as of 2026-09-07)
- Observed on GitHub-hosted runners,
comment-pr: true
Summary
ClaudeAPIClient.validate_api_access()hardcodesclaude-3-5-haiku-20241022, which Anthropic retired on 2026-02-19. Every run now fails that health check, andFindingsFilterreacts by disabling Claude-based false-positive filtering entirely. The action still reports success, so the degradation is silent.Where
claudecode/claude_api_client.py(currently onmain,0c6a49f1fa56a1d472575da86a94dbc1edb78eda):claudecode/findings_filter.py:Impact
not_found_errorrequest, so Anthropic sends users retired-model warning emails naming their API key. That is how we found this: three failed requests on a given day matched exactly three Security Lane runs.Note the
claude-modelinput does not help, since it setsself.modelfor analysis but not this hardcoded health-check model.Suggested fix
Use
self.modelfor the validation call rather than a hardcoded id, so it follows theclaude-modelinput and cannot rot again:Alternatively, pin the health check to a current model (
claude-haiku-4-5), though usingself.modelavoids a repeat of this in the future. It may also be worth making the filtering-disabled path louder thanlogger.warning, since users cannot tell filtering silently stopped.Environment
0c6a49f1fa56a1d472575da86a94dbc1edb78eda(also currentmainas of 2026-09-07)comment-pr: true