Debug Rls

When your frontend users complain they can't see their data or they're seeing everyone else's data, this is the protocol to follow. It walks through the four-step debugging process: check if RLS is enabled, inspect policy definitions, simulate different roles with `as_role` and `as_user` parameters, and verify auto-populate triggers are firing. The key insight is that MCP tools default to the service key and bypass all RLS, so you have to explicitly pass `as_role: "user"` to reproduce what real users experience. Includes a symptom matcher table and four copy-paste fixes for the most common misconfigurations. Saves you from guessing why a policy that looks correct still blocks legitimate requests.

GitHub stars: 532
last updated: Jun 11, 2026

View on GitHub

Install

$ npx -y skills add butterbase-ai/butterbase-skills --skill debug-rls --agent claude-code

Installs into .claude/skills of the current project.

Files

debug-rls

Systematic methodology for debugging Row-Level Security issues in Butterbase. Uses role simulation (as_role/as_user parameters) to verify policy behavior without needing real user sessions.

1. Overview

Row-Level Security (RLS) in Butterbase controls which rows each database role can see or modify. When RLS is misconfigured, users may see no data, too much data, or get unexpected errors on insert. This skill walks through a repeatable four-step process to identify and fix the root cause.

Key principle: MCP tools default to the service key (bb_sk_...), which bypasses all RLS. Always use as_role/as_user to simulate the role your frontend actually uses.