What happens
A read-only SELECT combining CTEs, joins, aggregate FILTER clauses, and EXISTS checks was rejected locally before reaching Postgres with a generic security-parser error. Each equivalent inspection succeeded when split into simple SELECT statements. This makes safe production metadata verification unnecessarily awkward.
Command
npx @insforge/cli db query <read-only CTE SELECT> --json
Error
Query could not be parsed and was rejected for security reasons. (FORBIDDEN)
Expected
The documented raw SQL inspection command should accept a valid read-only public-schema SELECT or explain the unsupported construct.
Workaround
Split the inspection into several simple read-only SELECT queries.
Triage finding
Reroute to InsForge/InsForge, not CLI — the CLI forwards SQL verbatim; the 403 comes from checkSqlExecutionGuards (backend/src/utils/sql-parser.ts:129), unchanged since 2026-07-11 and untracked by any issue. The users' stated cause is wrong (libpg-query 17.7.3 parses CTE+JOIN+FILTER+EXISTS fine, and the guard is a statement-type denylist that never restricts query shape), but the actionable defect is real: the catch block swallows libpg-query's actual syntax error and position, reporting every parse failure as a generic security refusal — which is what caused three users to misdiagnose it.
· darwin 25.1.0
Filed automatically from user feedback.
What happens
A read-only SELECT combining CTEs, joins, aggregate FILTER clauses, and EXISTS checks was rejected locally before reaching Postgres with a generic security-parser error. Each equivalent inspection succeeded when split into simple SELECT statements. This makes safe production metadata verification unnecessarily awkward.
Command
Error
Expected
The documented raw SQL inspection command should accept a valid read-only public-schema SELECT or explain the unsupported construct.
Workaround
Split the inspection into several simple read-only SELECT queries.
Triage finding
Reroute to InsForge/InsForge, not CLI — the CLI forwards SQL verbatim; the 403 comes from
checkSqlExecutionGuards(backend/src/utils/sql-parser.ts:129), unchanged since 2026-07-11 and untracked by any issue. The users' stated cause is wrong (libpg-query 17.7.3 parses CTE+JOIN+FILTER+EXISTS fine, and the guard is a statement-type denylist that never restricts query shape), but the actionable defect is real: the catch block swallows libpg-query's actual syntax error and position, reporting every parse failure as a generic security refusal — which is what caused three users to misdiagnose it.· darwin 25.1.0
Filed automatically from user feedback.