MINOR (test gap): no test covers target_warehouse: "". The change is correct: the native layer uses target_warehouse ?? source_warehouse, so "" used to reach the handler as a warehouse name rather than meaning the source. A test that passes target_warehouse: "" and checks the dispatched params (and that the ask names the source warehouse) would lock this in.

Blocker: no, test-only.

Added in 6b5b356: a runner test passes target_warehouse: "" and checks that the dispatched data.diff params carry the source warehouse and no target_warehouse. The ask resolves target_warehouse || source_warehouse. No test checks the ask with "" yet, so the test is named for what it does check: the dispatch.

MAJOR: dynamic SQL split across literals is no longer hard-blocked. main had, at this point:

else if (DYNAMIC_SQL.test(masked) && mentionsHardDeny(sql)) blocked = true

That reads the words of the whole text, so 'DROP ' + 'DATABASE x' counts. Its replacement, quotedHardDeny, checks each literal on its own, so the pair is never seen together. Each of these is blocked on main and write, blocked=false here, so it runs with --allow-write:

-- sqlserver
EXEC('DROP ' + 'DATABASE victim')
-- bigquery
EXECUTE IMMEDIATE CONCAT('DROP ', 'SCHEMA victim CASCADE')
-- mysql
SET @s = CONCAT('DROP ', 'DATABASE victim'); PREPARE p FROM @s; EXECUTE p
-- postgres: string constants separated by a newline are one string
DO 'BEGIN DROP '
'SCHEMA victim CASCADE; END'

Run: through mcp serve --allow-write on Postgres 18, the DO form is refused on main and drops the schema at this head. MySQL 8 drops the database with the PREPARE form. The docs now say concatenation can get past the check, but main caught these forms, so this is a regression of the hard block.

Fix: keep the base check next to the new one, e.g. if (DYNAMIC_SQL.test(maskSql(lexical.tokens)) && mentionsHardDenyAnywhere(sql)) blocked = true, and add the four inputs as blocked: true tests.

Fixed in b89c0b7. classifyAndCheck again has DYNAMIC_SQL.test(maskSql(tokens)) && mentionsHardDenyAnywhere(sql) next to quotedHardDeny. All four inputs (sqlserver EXEC with +, bigquery CONCAT, mysql PREPARE, postgres newline-joined DO) are blocked: true tests, and removing the check fails them. I also corrected the quotedHardDeny doc comment, which said concatenation is not seen. Side effect, now in Known limits: separate parameter values that together read as DROP ... CATALOG are refused, the same class as N'DATABASE' on main. Splitting inside a keyword ('DR' + 'OP DATABASE') still gets through, the same as on main.

[🟠 MEDIUM] Potential Regression in THROW Statement Matching

The regular expression for THROW was updated from \\bTHROW\\s*($|;|[\\d@]) to \\bTHROW\\s+[\\d@].

This change drops support for matching a bare THROW; statement or THROW at the end of a script (often used to re-throw exceptions in CATCH blocks). This could cause valid control-flow or write scripts in T-SQL to be misclassified as read-only.

Please verify if bare THROW statements are still supported or if the regex needs to be reverted to include ($|;|[\\d@]).

Bare THROW is still classified as a write: 'THROW;' and 'BEGIN CATCH THROW; END CATCH' both return write on tsql at HEAD. The narrower pattern only stops 'throw' used as an identifier from matching.

MAJOR: TRUNCATE without TABLE is no longer hard-blocked in positions the base blocked. The base matched \bTRUNCATE\b(?!\s*\() anywhere in code. This head matches TRUNCATE only as TRUNCATE TABLE, after ^/;/PREPARE … AS/EXPLAIN (…), after the block words on this line, or after THEN/ELSE. Each of these is blocked at the base and write, blocked=false here, so it runs with --allow-write:

• Snowflake: CREATE TASK k AS TRUNCATE t and CREATE OR REPLACE TASK k WAREHOUSE = w AS TRUNCATE t
• MySQL: CREATE PROCEDURE p() TRUNCATE t and CREATE PROCEDURE p() SQL SECURITY INVOKER TRUNCATE t. A single-statement routine body; MySQL procedures allow TRUNCATE.
• Postgres: CREATE PROCEDURE p() LANGUAGE sql BEGIN ATOMIC TRUNCATE t; END; CALL p(). NOT ATOMIC is listed, but in BEGIN ATOMIC the word ATOMIC sits before TRUNCATE.
• Oracle, MySQL and Databricks: ALTER TABLE t TRUNCATE PARTITION p. Oracle also: ALTER TABLE t TRUNCATE SUBPARTITION p.

The PR says the block "finds TRUNCATE in more positions"; for these forms it finds fewer. The same PR also starts blocking literal routine bodies (CREATE FUNCTION … AS 'TRUNCATE t'), so plain-text bodies are now the weaker side.

Suggested fix: apply the "a target must follow" rule after any preceding token except .:
\bTRUNCATE\s+(?!(FROM|AS|WHERE|ORDER|GROUP|HAVING|UNION|LIMIT|WINDOW|INTO|JOIN|ON|AND|OR|END)\b)[\w"$\u0080-\uffff]With that ruleSELECT truncate FROM t, ORDER BY truncateandAS truncate,stay reads, whileAS TRUNCATE t, ) TRUNCATE t, ATOMIC TRUNCATE tandTRUNCATE PARTITION p` are blocked. Please add a test for each form.

Fixed in 6b5b356. TRUNCATE followed by a target is now a statement wherever it sits, so these are blocked again, each with a test:

• CREATE [OR REPLACE] TASK k ... AS TRUNCATE t
• CREATE PROCEDURE p() [SQL SECURITY INVOKER] TRUNCATE t
• BEGIN ATOMIC TRUNCATE t
• ALTER TABLE t TRUNCATE [SUB]PARTITION p, on Oracle, MySQL and Databricks

A column named truncate stays a read when what follows it is a clause word, an operator, , or ), or when it is qualified, including with a comment between, as in t./*c*/truncate. That covers FROM, ORDER BY ... DESC, ISNULL, window frames (ROWS/RANGE), WITH ROLLUP, SETTINGS, OPERATOR(...) and ASCENDING.

The qualified-name check runs only after TRUNCATE has matched, so classification stays linear; there are timing tests on 400 KB inputs.

Two limits are documented in the description. A name truncate followed by any other word is refused, for example an alias without AS (SELECT truncate x, FROM truncate t). A target that is itself one of those clause words (TRUNCATE nulls) is not caught.

[🟠 MEDIUM] High Complexity and Maintainability Risk

The CODE_HARD_DENY (and BATCH_STATEMENT) regular expressions have become extremely long strings constructed via concatenation and contain dense assertions (like negative lookaheads).

This approach makes them:

1. Hard to read and maintain for other developers.
2. Prone to escaping errors.
3. Vulnerable to Regular Expression Denial of Service (ReDoS) issues if backtracking behaves unexpectedly with complex SQL inputs.

Consider breaking these regex patterns down into smaller, well-named, and independently tested segments, or replace some of this logic with structural AST checks where possible. Make sure there is extensive unit testing for the edge cases introduced here.

The patterns are assembled from commented parts and are covered by the adversarial and read-safety suites. No input that backtracks badly or misclassifies is given, so no change.

[🟠 MEDIUM] Redundant Tokenization

The classifySql function (called just above) already executes tokenizeSql(sql, dialect) internally. Calling it again here for write queries introduces unnecessary CPU overhead and latency, especially for large SQL statements.

Consider modifying classifySql to return the lexical analysis result along with its classification so that you can reuse it here without redundant processing.

Correct, a second tokenize runs, but only for non-blocked write queries and it is linear in the SQL length. Returning the lexical result from classifySql is possible but changes its signature; leaving as is unless it shows up in profiling.

MAJOR: an existing test now fails. This new literal check blocks INSERT INTO logs VALUES ('TRUNCATE TABLE users happened') (blocked=true). test/altimate/sql-validation-adversarial.test.ts:116-120 ("TRUNCATE inside string literal is not blocked") still asserts blocked: false. That file passes at the base (73/73) and fails at this head (72 pass / 1 fail). A full bun test test/altimate run at head gives 10646 pass / 1 fail, and this is the only failure that is new at head. This stacked PR's checks run no test job, so nothing flags it.

Fix: change the expectation to blocked: true with a note that it is the accepted "literals mentioning TRUNCATE in writes" limit, or move the case into the new table in sql-classify.test.ts.

Fixed in 6b5b356. The test now expects blocked: true for INSERT INTO logs VALUES ('TRUNCATE TABLE users happened'), with a note that this is the accepted limit: a write's literals are read as SQL, so a write whose literal names TRUNCATE is refused even with --allow-write. sql-validation-adversarial.test.ts passes, and the run on the touched files is 1841 pass, 0 fail.