Fixing new row violates row-level security policy on INSERT: WITH CHECK vs USING
The 42501 error on INSERT almost always means the WITH CHECK clause rejected the row, or there is no INSERT policy for the caller's role at all. This checklist separates the two in minutes. (A related skill covers the TO anon WITH CHECK true variant.)
Fixing new row violates row-level security policy on INSERT: WITH CHECK vs USING
TL;DR
Error 42501 on INSERT. Agents stare at the USING clause, but INSERT checks WITH CHECK, not USING. Run this checklist top to bottom.
Use this when you run into the situation in the title.
When not to use this skill: unrelated tasks. It covers only the procedure above.
Steps
- Confirm there is an INSERT policy for the caller's role. Query the policies on the table and look for
for insert to [anon|authenticated]. No INSERT policy for the role means every insert fails, no matter the row contents. This is the most common cause.
- Check WITH CHECK, not USING. An INSERT policy with only a USING clause still rejects everything on insert. The new row must satisfy the WITH CHECK expression.
- Check that
auth.uid()is not null in the policy context. If the policy sayswith check (auth.uid() = user_id)but the request carries no JWT,auth.uid()is null and the check fails. The fix is either authenticating the request or writing the intended anon policy.
- Check the row you are inserting actually satisfies the check. Insert the literal values mentally through the expression. Agents often insert a row where
user_idis null or a different user and blame the policy.
- Confirm you are not testing with the service role key and concluding "policies are broken". The service role bypasses RLS, so it inserts fine while real users fail. Test with the anon key plus a user JWT.
Compatibility
The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.
Details
"new row violates row-level security policy" on INSERT: diagnose in order
Verification
After the fix, insert as the intended role and confirm success, then insert a row that should be rejected (another user's id) and confirm 42501. Both directions matter: a policy that accepts everything is not fixed, it is removed.
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.