Supabase RLS静默失败主因是策略未启用或条件不匹配：需确认RLS开关为绿色、auth.uid()非NULL、USING/WITH CHECK逻辑正确，并用anon/authenticated角色真实模拟测试。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在 Codex Supabase 插件中启用 RLS 后执行查询却收到 permission denied 或 no rows returned 错误，不是策略没生效，就是策略条件与当前会话角色/上下文不匹配——Supabase 不会告诉你哪条策略拦住了你，只默默拒绝。
确认 RLS 已真正启用
进入 Supabase Studio → Table Editor → 点击目标表名右侧的「RLS」开关图标 → 确保状态为绿色「Enabled」。若显示灰色或「Disabled」，点击开启；【仅开启开关不等于策略生效，必须至少存在一条通过验证的 POLICY】。
在 SQL Editor 中运行：SELECT relname, relrowsecurity FROM pg_class WHERE relname = 'your_table_name'; → 若返回 relrowsecurity = false，说明 RLS 实际未启用，需手动执行 ALTER TABLE your_table_name ENABLE ROW LEVEL SECURITY;。
策略写错？先查 auth.uid() 是否可取
在 SQL Editor 中执行：SELECT auth.uid(); → 若返回 NULL，说明当前会话未认证（比如用了 anon key 但未登录，或 service_role 密钥绕过了 auth 上下文）。
前端调用时务必使用已登录用户的 client：确保初始化 Supabase 客户端后，已调用 await supabase.auth.signInWithPassword(...) 或类似方法完成登录；【anon key + 未登录 = auth.uid() 为 NULL，所有依赖 auth.uid() 的策略必然失败】。
测试策略是否能捕获真实用户 ID：插入一条测试记录，再用已登录账号执行 SELECT * FROM your_table WHERE user_id = auth.uid(); —— 若能查到，说明 auth.uid() 可用；查不到则检查 user_id 字段类型是否与 auth.uid() 返回的 uuid 一致（常见错误：user_id 设为 TEXT 而非 UUID）。
策略语法与逻辑调试三步法
第一步：确认策略绑定的操作类型正确。例如想控制读取，却写了 FOR INSERT 策略，SELECT 仍被默认拒绝。
第二步：区分 USING 和 WITH CHECK。SELECT/UPDATE/DELETE 用 USING (condition) 控制「能否看到/改删该行」；INSERT/UPDATE 用 WITH CHECK (condition) 控制「插入/更新后的值是否合规」。漏写 WITH CHECK 会导致 INSERT 成功但 UPDATE 失败，或允许插入非法数据。
配置 OpenClaw 多提供商认证与 OpenAI Codex OAuth 备用方案，实现自动模型切换，适用于多 OpenAI Codex 账户设置。
第三步：用真实角色模拟请求。在 SQL Editor 右上角切换「Role」为 anon 或 authenticated，再执行 SELECT/INSERT 语句——这一步最接近前端真实环境，比用 service_role 直接查表更有诊断价值。
常见报错对应修复清单
方法一：报错 permission denied for table xxx
→ 检查是否遗漏 GRANT SELECT ON TABLE xxx TO anon; 或 TO authenticated;。RLS 开启后，PostgreSQL 会忽略默认权限，必须显式授权角色访问表本身。
方法二：报错 new row violates row-level security policy
→ 问题出在 INSERT 或 UPDATE 的 WITH CHECK 条件。例如策略写成 WITH CHECK (auth.uid() = user_id AND status = 'pending')，但代码中传入了 status: 'published'，直接被拒。
方法三：查询返回空数组，但表里明明有数据
→ 打开浏览器开发者工具 → Network 标签页 → 找到对应 Supabase 请求 → 查看 Response Headers 中的 x-supabase-api-version 和响应体是否含 error 字段；同时确认前端调用时是否传了 { count: 'exact' } 之类参数触发了隐式策略校验路径。
