[BUG]

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?

Subject: Token Credit Request - Extended Debugging Due to RLS Infinite Recursion Issue

Hello,

I'm requesting a token credit for an extended debugging session in Claude Code where a fixable issue resulted in excessive token usage.

What Happened:

During session 825efcac-7a86-4306-86a6-ef46d06b68cf, Claude was helping me implement Row Level Security (RLS) policies for a Supabase members table. Claude created migration 030 that resulted in an infinite recursion error because the RLS policy was querying the members table within itself, triggering the same policy recursively.

The Problem:

This is a well-known Supabase RLS pattern issue. The correct solution is to use a SECURITY DEFINER function to bypass RLS when checking permissions. However, Claude created 9 sequential migrations (migrations 023-031) attempting various approaches before finally implementing the correct solution with the SECURITY DEFINER function.

Token Usage:

The debugging process consumed approximately 50,000+ tokens across:

Multiple failed migration attempts
Repeated explanations and policy rewrites
Back-and-forth troubleshooting
Finally arriving at the correct solution that should have been implemented initially
Resolution:

The issue was ultimately resolved in migration 031 by using a SECURITY DEFINER function, which is the standard approach for this exact scenario. This solution could have been implemented from the start, avoiding the entire debugging chain.

I appreciate Claude's help overall, but I believe this represents a case where the extended token usage was due to an initial implementation error rather than legitimate problem-solving complexity. Take that as you may - that was costly..

Thank you,

Chris Callahan

What Should Happen?

Claude should recognize that RLS policies querying the same table they protect will cause infinite recursion, and immediately implement the standard solution using SECURITY DEFINER functions.

Specifically, when creating migration 023 (or 030, whichever first introduced the problematic policy), Claude should have:

1- Recognized the pattern: "RLS policy on members table with EXISTS clauses querying members table = infinite recursion"
2- Immediately created a SECURITY DEFINER function (like the one in migration 031) that bypasses RLS when checking permissions
3- Used that function in the policy USING clause

This would have avoided migrations 023-030 entirely, saving approximately 50,000+ tokens and significant debugging time. The solution in migration 031 is the correct and standard approach that should have been implemented from the start.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce:

1. User requested implementation of RLS (Row Level Security) policies for a Supabase members table
2. Claude created migration files (starting with migration 023) that implemented RLS policies with EXISTS clauses querying the members table within the members table's own policy
3. This created an infinite recursion error: "infinite recursion detected in policy for relation members" (PostgreSQL error code 42P17)
4. Instead of immediately recognizing this as a standard RLS pattern issue requiring SECURITY DEFINER functions, Claude created 8 sequential migrations (023 through 030) attempting various fixes:

--Trying different policy syntax
--Attempting TO authenticated/TO anon role specifications
--Simplifying EXISTS queries
--Multiple DROP/CREATE policy iterations

1. After extensive debugging consuming significant tokens, user suggested the issue might be "something related to the connection between users and members"
2. Only then did Claude implement the correct solution in migration 031: using a SECURITY DEFINER function to bypass RLS when checking permissions
3. This is a well-documented Supabase/PostgreSQL pattern that should have been used from the start

Expected Behavior:
Claude should have immediately recognized the need for SECURITY DEFINER functions when creating RLS policies that need to query the same table they're protecting, avoiding the entire debugging sequence.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.20

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_