Describe the bug
The built-in sql tool rejects otherwise valid SQL when a blocked statement keyword appears only inside a quoted string literal. This prevents ordinary prose from being stored in todo titles or descriptions even though the keyword is data, not executable SQL.
Affected version
1.0.71-1
Steps to reproduce the behavior
Invoke the built-in sql tool with this read-only query:
SELECT 'create and attach the item' AS description
The tool rejects the query before SQLite executes it:
Blocked SQL statement: "attach" is not allowed for security reasons.
The same failure occurs when attach appears in a quoted todo description inside an INSERT statement.
Expected behavior
The SQL safety validator should distinguish executable statement tokens from quoted literal content. Blocked commands such as ATTACH should remain rejected when used as SQL syntax, while the same text inside a string literal should be allowed.
Additional context
- macOS / Darwin
- Reproduced with a read-only
SELECT; no database write is required.
- The current workaround is to reword persisted prose, which is fragile and can silently lose intended content.
Describe the bug
The built-in
sqltool rejects otherwise valid SQL when a blocked statement keyword appears only inside a quoted string literal. This prevents ordinary prose from being stored in todo titles or descriptions even though the keyword is data, not executable SQL.Affected version
1.0.71-1Steps to reproduce the behavior
Invoke the built-in
sqltool with this read-only query:The tool rejects the query before SQLite executes it:
The same failure occurs when
attachappears in a quoted todo description inside anINSERTstatement.Expected behavior
The SQL safety validator should distinguish executable statement tokens from quoted literal content. Blocked commands such as
ATTACHshould remain rejected when used as SQL syntax, while the same text inside a string literal should be allowed.Additional context
SELECT; no database write is required.