The DELETE query uses string interpolation without parameterization. While sessionId comes from function params, lack of consistent parameterization creates injection risk.

sessionId from CLI is passed directly to deleteOpencodeSession without validation or sanitization. Unlike claude-code sessions (line 1416 in router.ts), no input filtering is applied, allowing arbitrary session IDs to be targeted.

homeDir parameter is used in path construction without validation, allowing potential access to arbitrary database files via path traversal (e.g., '../../malicious').

safeParse uses 'as T' without validation. Malformed database content could cause runtime errors when code assumes properties exist.

Empty catch blocks in listOpencodeSessions and getOpencodeSessionMessages return empty results without logging, making database errors invisible and hard to debug.

Empty catch blocks in listOpencodeSessions and getOpencodeSessionMessages return empty results without logging, making database errors invisible and hard to debug.

If withDb callback throws before queries execute, database connection may not close properly. While finally block exists, exceptions during db.close() could mask original error.

parser.ts lines 456 and 519 still reference old path '.local/share/opencode/storage' while constants.ts was updated to '.local/share/opencode'. These appear to be unused dead code functions, but if called will fail to find sessions.

deleteOpencodeSession only deletes from the session table but leaves orphaned records in message and part tables. Without CASCADE constraints or explicit cleanup, deleted sessions leak data.