Bug: Gemini browser mode fails on Linux due to SQLite BigInt overflow

[postpersonality]

Summary

Oracle's Gemini web/cookie mode fails on Linux with the error "Value is too large to be represented as a JavaScript number" when reading Chrome/Chromium cookies database, even when cookies are present and valid.

Environment

• OS: Fedora 42 (Linux)
• Oracle version: 0.8.5
• Node version: 22.16.0
• Browser: Chromium (system package)

Steps to Reproduce

1. Have Chromium with logged-in Google account at gemini.google.com

2. Verify cookies exist in Chromium profile:

   sqlite3 ~/.config/chromium/Default/Cookies \
     "SELECT name FROM cookies WHERE name LIKE '%PSID%';"

   Output shows __Secure-1PSID, __Secure-1PSIDTS, etc.

3. Run Oracle:

   oracle --verbose --engine browser --model gemini-3-pro \
     --browser-cookie-path ~/.config/chromium/Default/Cookies \
     --prompt "Say hello"

Expected Behavior

Oracle reads cookies and communicates with Gemini.

Actual Behavior

Oracle fails with:

[gemini-web] Starting Gemini web executor (TypeScript)
[gemini-web] Cookie warnings:
- Failed to read Linux keyring via secret-tool; v11 cookies may be unavailable.
- node:sqlite failed reading Chrome cookies (requires modern Chromium, e.g. Chrome >= 100): Value is too large to be represented as a JavaScript number: 13449189465095212
[gemini-web] Loaded Gemini cookies from Chrome (node): 0 cookie(s).
ERROR: Gemini browser mode requires Chrome cookies for google.com (missing __Secure-1PSID/__Secure-1PSIDTS).

Root Cause Analysis

The error "Value is too large to be represented as a JavaScript number: 13449189465095212" suggests that a column in the Cookies SQLite database (likely expires_utc or last_access_utc) contains a value exceeding JavaScript's Number.MAX_SAFE_INTEGER (9007199254740991).

Chrome stores timestamps in microseconds since January 1, 1601 (Windows FILETIME epoch). The value 13449189465095212 is a valid Chrome timestamp (~2026).

The node:sqlite module apparently fails when encountering these large integers without BigInt handling.

Suggested Fix

Use BigInt when reading timestamp columns from the Cookies database, or configure the SQLite driver to return BigInts for INTEGER columns. Example with better-sqlite3:

// Option 1: Cast to string in SQL
const cookies = db.prepare(`
  SELECT name, encrypted_value, host_key, 
         CAST(expires_utc AS TEXT) as expires_utc
  FROM cookies WHERE host_key LIKE ?
`).all('%google.com');

// Option 2: Use BigInt mode if driver supports it

Workaround

None found. Tested with:

• --browser-cookie-path with explicit path to Cookies database
• Fresh Chromium profile
• Different cookie encryption modes (--password-store=basic)

Additional Context

• The keyring warning ("Failed to read Linux keyring via secret-tool") is a separate issue but not the root cause here
• Cookies are confirmed to be in the database and accessible via sqlite3 CLI
• This appears to be a Linux-specific issue due to how timestamps are handled

[steipete]

Small improvement landed in ea47dcc: Gemini missing-cookie failures now surface the underlying cookie-reader warnings and point at / , so the Linux BigInt failure is easier to diagnose. Keeping this open because the Node 22 / cookie-reader overflow path itself still needs a real fallback or upstream fix.

[steipete]

Correction to the mangled shell-rendered comment above:

Commit ea47dcc6 improved Gemini browser-mode diagnostics. Missing-cookie failures now surface the underlying cookie-reader warnings and explicitly suggest --browser-manual-login or --browser-inline-cookies-file, so the Linux node:sqlite BigInt failure is easier to diagnose.

Keeping this open because the Node 22 / cookie-reader overflow path itself still needs a real fallback or upstream fix.