feat: refresh __Secure-1PSIDTS so the session survives past an hour

[cheungringo420]

Based on pr-80 (upstream PR Sophomoresty#80 head, 434cb65) — the branch this deployment actually runs.

Problem

A cookie file written once goes stale in roughly an hour. Google rotates __Secure-1PSIDTS and stops honouring the previous value; a browser keeps up because it keeps calling accounts.google.com/RotateCookies, but a file-backed jar never does.

The failure is easy to misread, which is what made it expensive to diagnose:

• anonymous Gemini still answers text prompts, so the text path looks healthy
• content-push.googleapis.com accepts uploads with no credentials at all (verified: zero cookies, bogus X-Tenant-Id — still returns a /contrib_service/ttl_1d/... ref), so Image uploaded: in the log proves nothing

Only the account-only work fails, and it surfaces as BardErrorInfo [1100] on image input rather than as anything auth-shaped.

Why not passive Set-Cookie capture

Measured against the live endpoint — Gemini's own replies carry only NID, never a rotated __Secure-1PSIDTS:

[GET /app (urllib)]               Set-Cookie count=1  -> NID
[POST StreamGenerate (curl_cffi)] Set-Cookie count=1  -> NID

So the rotation endpoint has to be called explicitly.

Change

A daemon thread polls accounts.google.com/RotateCookies every cookie_refresh_interval_sec (default 540s; the endpoint's own hint in its 401 body is 600) and merges any new value back into cookie_file.

• writes back only __Secure-1PSIDTS / __Secure-3PSIDTS, leaving long-lived cookies alone
• re-reads the file under a lock before merging, so a concurrent write from a cookie-sync browser extension is merged into rather than overwritten
• atomic os.replace where possible, falling back to an in-place rewrite on EBUSY — a bind-mounted cookie file cannot be replaced, and that is the normal Docker layout
• the temp file holds a full copy of the session, so it is removed on every path including failures
• write_failed is reported distinctly from unchanged, with a hint, so a read-only cookie file cannot look like "nothing to do"
• updates gemini.py's mtime-keyed cache so in-flight requests pick the new value up
• 401 leaves the file byte-for-byte unchanged and backs the loop off ×4
• handles both the JSON and plain-cookie-string file formats
• cookie_refresh_enabled: false to opt out; never creates the file

Verification

• 78 unit tests pass (54 existing + 24 new) — python -m unittest discover -s tests
• ruff check clean on every changed file (the remaining E722 is pre-existing in server.py, untouched)

Live against Google from the deployment VM, signed-in session — success path:

before: ...51ZNoXeA5FZan6zCNGYEAA
rotate -> True __Secure-1PSIDTS,__Secure-3PSIDTS
after : ...ZdqCoiiO_Xw-GHOnrPqEAA
VALUE ROTATED: True     temp files: none     mode: 0o600
cache serves persisted value: True     cookies intact: 11 | sapisid: True

Live — signed-out session: rotate -> False unauthorized, file byte-identical, no temp file.

Live — read-only bind mount: rotate -> False write_failed with the hint, file byte-identical, no temp file.

The first three of those behaviours were found by live testing: the initial cut failed with EBUSY on the bind mount, left a full copy of the session in the directory, and reported the failure as unchanged. Fixed in the second commit.

Deployment note

docker-compose.yml mounts the auth file read-only:

- ./gemini-auth.json:/app/gemini-auth.json:ro

Drop the :ro or the refresher can never persist anything — it will log write_failed every cycle and the session will still expire.

Rate limiting

RotateCookies returns 429 if called repeatedly in quick succession, which is worth knowing before lowering cookie_refresh_interval_sec.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.