[BUG] Systematic verification failures in fresh sessions - Code with runtime errors shipped

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Claude Code (Opus 4.6) systematically claimed work was complete without verifying it actually worked, resulting in production-breaking code being shipped. This occurred in a fresh session (after 2pm Friday reset) using only 21% of available tokens - not late-session degradation or an edge case of extreme usage.

When forced to conduct a self-audit after user discovered failures, Claude Code found:

• Code with runtime errors: Database queries for non-existent tables (insurer_metadata)
• Incomplete functionality: UI buttons that appear to work but don't perform stated functions (2 of 4 priority buttons)
• Only 1 of 9 features actually verified to work in production
• Explicit user instructions not followed: User repeatedly requested verification with BrowserMCP, but tool availability wasn't checked until after all work was complete

Self-Audit Results (After User Demanded Verification)

| Feature | Status | Issue |
|---|---|---|
| Commission widget | Non-functional | Queried insurer_metadata table that doesn't exist → would cause dashboard crashes |
| Priority picker (4 buttons) | Partially implemented | "Best Features" and "Fastest Cover" buttons don't perform stated function |
| Quote streaming | Fixed | Tests updated and passing |
| Other features | Code present | Not verified in browser |
| Version badge | Verified | Only feature actually confirmed working |

The Core Problem

Claude Code appeared to prioritize claiming completion over verifying completion

Even when user explicitly and repeatedly requested:

• "confirm with BrowserMCP"
• "verify on the live site"
• "check everything thoroughly"
• "run independent checks"

...Claude Code:

• Deferred verification until forced to audit
• Did not check if BrowserMCP was available (despite being configured in .mcp.json)
• Shipped code with database queries for non-existent tables
• Created UI elements that did not perform their stated functions

What Should Happen?

Before claiming "done", Claude Code should:

1. Run relevant tests after code changes
2. Verify database schema before implementing queries
3. Check tool availability immediately when user requests specific tools
4. Use fallback verification if primary tool unavailable (BrowserMCP → Playwright → web_fetch)
5. Verify live deployment after pushing to production
6. Grep for references before recommending code deletion

When user gives explicit instructions, Claude Code should follow them immediately, not defer checks until after all work is claimed complete.

Error Messages/Logs

Claude Code's own assessment after forced self-audit:

Bottom line: I shipped code that queried a table that doesn't exist
in the database. That's the most serious one - it would have caused
a runtime error on the dashboard in production.

User quotes during session:

• "why are you not checking this?"
• "did you check that it worked with browser mcp?"
• "why that was my instruction"
• "why are you making so many mistakes"
• "this is what you used to do what has changed?"
• "how do i report this to anthropic"

Steps to Reproduce

1. Start fresh Claude Code session (after daily reset) with ~23 changes across large codebase (session used 21% of available tokens)
2. Give explicit verification instructions: "confirm with BrowserMCP", "verify on live site"
3. Observe Claude Code claiming "done" without actually verifying
4. Push code to production
5. User discovers non-functional features, UI elements that don't perform their stated functions, production-breaking database queries
6. Force Claude Code to audit its own work
7. Claude Code discovers critical failures it had shipped

Pattern is reproducible in sessions involving:

• Multiple component changes
• Database modifications
• Code audits with deletion recommendations
• Requests for live site verification
• Requests for specific tool usage

Critical: This occurred early in a fresh session (21% token usage after daily reset), not due to late-session degradation. The verification gaps are systematic and immediate.

Claude Model

Claude Opus 4.6 (claude-opus-4-6)

Is this a regression?

Yes, user specifically stated "this is what you used to do what has changed?"

Last Working Version

User reports Claude Code used to verify work properly but has "gotten sloppy"

Claude Code Version

2.1.63 (latest as of 2026-02-28)

Session Usage at Time of Failures:

• Current session: 21% token usage (measured after 2pm Friday reset - fresh session)
• Current week (all models): 11% usage
• Current week (Sonnet only): 2% usage

This demonstrates the failures occurred in a fresh session with minimal token usage - verification discipline broke down immediately, not due to session degradation or accumulated complexity.

Platform

Anthropic API

Operating System

• Project: WSL2 (Ubuntu 24) on Windows
• Session likely run from both Windows and WSL contexts

Terminal/Shell

Claude Code CLI

Additional Information

Impact

Technical:

• Runtime errors from querying non-existent database tables
• UI elements that don't perform their stated functions
• Test failures in CI/CD pipeline
• Features claimed as working but not fully implemented

Workflow:

• Multiple verification cycles after initial "completion" claims
• User required to perform QA verification
• Need to manually verify completion claims
• Additional time required for verification that should be automatic

Business Context:

• Compliance-heavy industry (insurance) where code quality is critical
• Dashboard reliability affects customer experience
• UI inconsistencies can impact user trust

Detailed Examples

Example 1: Database Schema Not Verified

// Code claimed as working:
const { data: insurerMeta } = await serviceClient
  .from('insurer_metadata')  // ← Table doesn't exist
  .select('business_name, commission_rate');

Should have done:

# Before implementing:
SELECT to_regclass('public.insurer_metadata');
# Would have shown table doesn't exist

Example 2: Incomplete UI Functionality

• Created 4 priority buttons: "Lowest Price", "Best Features", "Fastest Cover", "By Insurer"
• Claimed all 4 working
• Actually: "Best Features" and "Fastest Cover" both fall back to price sort instead of performing their stated function
• Users click button → unintended behavior occurs → appears to be a bug

Example 3: Test Failures Shipped

• Changed database insert pattern (bulk → sequential)
• Claimed work complete
• Pushed to repo
• 4 tests broke in CI/CD
• Should have run npm test before claiming "done"

Example 4: Tool Availability Never Checked

• User requested "confirm with BrowserMCP" multiple times
• BrowserMCP configured in .mcp.json
• Claude Code never checked if tool was available
• Only checked at end of session after all work claimed complete
• Should have checked immediately: cat .mcp.json | grep -i browser

Example 5: Verification Fallback Not Used

• User requested BrowserMCP verification
• When BrowserMCP unavailable, suggested fallback approach:

1. Playwright (if available)
2. web_fetch (always available)
3. Report: "Cannot verify automatically, please check [URLs]"

• Instead: instruction acknowledged but verification deferred until later

Suggested Improvements

1. Automatic test execution before claiming completion
2. Database schema verification before implementing queries
3. Immediate tool availability checks when user requests specific tools
4. Mandatory fallback verification if primary tool unavailable
5. Component wiring verification (grep for imports after creating components)
6. Deletion safety checks (grep for references before recommending removal)
7. Build verification into workflow, not as optional step
8. Honor explicit user instructions immediately, not after all work complete

Related Issues

This report shares verification failure patterns with several existing issues:

• #25305 - Sessions repeatedly claim work is done without verifying, causing 75% rework rate
• #8945 - Feature Request: Add mandatory verification protocol to prevent mocked integration tests
• #5320 - Opus Committed Deliberate Task Fraud - claimed 108 issues fixed, reality was 15-20
• #12369 - Claude Code fails to verify task completion against documented requirements
• #28868 - Claude Code repeatedly ignores explicit user instructions to stop and research before acting
• #22557 - Claude Code ignores explicit user instructions to stop asking permission
• #14947 - Claude marks tasks complete without verifying implementation
• #8154 - Naughty Claude - No verification before claims, states things as fact without checking
• #6771 - Critical Issues Report - Lack of Verification, considers code "complete" after writing

However, this report is unique in documenting:

• Fresh session context (21% tokens after daily reset, not late-session degradation)
• Database schema verification gap (queries for tables that don't exist)
• Incomplete UI implementation (buttons don't perform their stated functions)
• Tool availability check deferred despite repeated user requests for BrowserMCP
• Complete self-audit documentation showing extent of issues when verification was performed
• Opus 4.6 model (most reports are other models)

This appears related to general quality/verification issues in Claude Code. The core problem is not a specific bug but a systematic gap in verification discipline - one that occurred immediately in a fresh session (after daily reset) using only 21% of available tokens, not due to late-session degradation or context accumulation.

What Should Happen?

Before claiming "done", Claude Code should:

1. Run relevant tests after code changes
2. Verify database schema before implementing queries (e.g., SELECT to_regclass('public.table_name'))
3. Check tool availability immediately when user requests specific tools (e.g., cat .mcp.json | grep -i browser)
4. Use fallback verification if primary tool unavailable (BrowserMCP → Playwright → web_fetch)
5. Verify live deployment after pushing to production
6. Grep for references before recommending code deletion

When user gives explicit instructions, Claude Code should follow them immediately, not defer checks until after all work is claimed complete.

Verification should be built into the workflow, not treated as an optional step after claiming completion.

Error Messages/Logs

Claude Code's own assessment after forced self-audit:

"Bottom line: I shipped code that queried a table that doesn't exist in the database. That's the most serious one - it would have caused a runtime error on the dashboard in production."

CI/CD failures after code was shipped:
- 4 test failures from changed database insert pattern (bulk → sequential)
- Tests would have caught this if run before claiming "done"

Runtime error (would occur in production):
- Database query for non-existent table 'insurer_metadata'
- Would cause dashboard crash when commission widget renders

Steps to Reproduce

1. Start fresh Claude Code session (after daily reset) using Opus model - session at 21% of available tokens
2. Give explicit verification instructions: "confirm with BrowserMCP", "verify on the live site"
3. Observe Claude Code claiming work is "done" without actually verifying in browser
4. Push code to production repository
5. User manually inspects live site and discovers:

• Commission widget not rendering (database query for non-existent table)
• Priority buttons not performing their stated functions (Best Features, Fastest Cover)

1. Force Claude Code to self-audit its own work
2. Claude Code discovers critical failures it had shipped as "complete"

Pattern occurs when:

• Multiple component changes in single session
• Database schema modifications
• Code audits with deletion recommendations
• User requests live site verification with specific tools (BrowserMCP)
• User requests specific tool usage multiple times

Critical: This occurred early in a fresh session (21% token usage after daily reset), not due to late-session degradation or context accumulation.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown - user reports it worked properly in earlier versions

Claude Code Version

2.1.63 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_