[MODEL] Applied production DB permission revocation without checking view dependencies, causing app-wide outage

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

I confirmed (after Claude proposed it) that it should apply a pre-written Postgres
security-hardening migration to the PRODUCTION database, which revokes EXECUTE
privilege on several SECURITY DEFINER functions from the anon/PUBLIC roles,
under the explicit condition that it must not break the app for testers currently using it.

What Claude Actually Did

1. Reviewed the migration and correctly identified ONE risky line (revoking anon

access to a different function used by an audio feature) by cross-referencing
it against actual Dart source code comments, and excluded that single line.

1. Did NOT apply the same cross-reference check to another function in the same

migration: _artist_is_claimed(uuid).

1. Applied the migration, revoking anon's EXECUTE on _artist_is_claimed(uuid).
2. This function is called inside the SELECT list of a Postgres VIEW

(public_artist_catalog_view) that powers the app's home screen (artist
listings, "top artists", "featured" sections).

1. Because the view has no SECURITY DEFINER wrapper, it executes as the calling

role. Requests that hit the database before the user's auth session fully
restores (a known race condition already documented elsewhere in the same
codebase) run as anon, which now lacked EXECUTE on that function.

1. The view failed for those requests. The app's own error handling silently

caught the exception and returned an empty list instead of surfacing an error.

1. Result: for hours, the home screen showed no images and empty

"featured"/"top artists" sections for users, with zero errors reported to
Sentry (crash reporting), because the failure was swallowed client-side.

1. The issue was only found because the user manually tested the live app and

reported broken images — Claude had no independent signal that anything
was wrong.

Expected Behavior

laude should have checked EVERY function being revoked against both:
(a) RLS policies that reference it (which it did check), AND
(b) SQL VIEW definitions that reference it in their SELECT list (which it
did not check)
before applying any revoke, applying the same diligence uniformly rather than
only to the one function it happened to cross-reference against application
source code.

Files Affected

No local repository files were modified for this specific action. This was a
direct schema/permission change applied to the live production Postgres
database (Supabase) via an MCP tool call (apply_migration), affecting:
  - Function: public._artist_is_claimed(uuid) — EXECUTE revoked from `anon`
  - Downstream: public_artist_catalog_view (broken for anon-context reads)

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Ask Claude to review and apply a database migration that revokes EXECUTE

privilege on several functions from a public-facing role.

1. Include at least one function in that set which is referenced inside a

SQL VIEW's SELECT list rather than directly called by client code or used
in an RLS policy.

1. Observe whether Claude checks view definitions (e.g. via

pg_get_viewdef/pg_views) for every function, or only for the ones it
happens to cross-reference against other call sites.

Claude Model

Sonnet

Relevant Conversation

Claude wrote, immediately before applying the migration: "Achei um problema
real na migration 1: linha 107 revoga anon de get_song_dsp_features_for_app...
vou aplicar tudo, exceto essa linha específica." This shows Claude was capable
of, and did perform, this exact class of dependency check for one function —
it simply didn't apply it to every function in the same migration.

Impact

High - Significant unwanted changes

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Additional Context

This incident happened inside a longer session where the same underlying
pattern — asserting something was checked/complete without full verification,
only correcting course after explicit user pushback — showed up repeatedly:

• An incomplete CI fix was declared without confirming it fully resolved

the original failure (a different error surfaced ~40 minutes into the
next CI run).

• A stale build artifact was offered for upload without checking it matched

the just-bumped app version; only caught because the user asked a
clarifying question.

• An anomaly the user reported was given a shallow explanation on first

mention, and only received a rigorous root-cause investigation after the
user explicitly demanded it.

• When information was missing, the assistant asked the user to supply it

manually instead of first searching the local repository, where the
answer was already present in an existing file.

• Separately (different context, not a Claude Code bug specifically), the

assistant asserted that a /bug slash command exists in Claude Code,
which is incorrect — no verification was performed before stating it as
fact.