cold-store-reaper: live Google access token is cached in state.json, which the README calls '(no secrets)' and which is written without 0600 permissions #940

Finding

cold-store-reaper caches a live Google OAuth access token in state.json, while the README describes state.json as "(no secrets)" and the file is written without the restrictive permissions the package applies to real credentials. Anyone or anything that can read state.json (backups, sync tools, another process in a less-protected home) holds a working Drive bearer token for its lifetime (~1h).

Found by the pr-diff-review job reviewing PR #923 (cold-store-reaper v1), 2026-10-25; verified on current main (92d0c6ee).

Evidence

• pkgs/cold-store-reaper/README.md:52: state.json # folder IDs + cached access token (no secrets) — the sentence contradicts itself: a cached access token is a credential.
• pkgs/cold-store-reaper/cold_store.py:332 (in access_token()): state["access_token"] = token, persisted via save_state() (lines 228-229) → _write_json() (line 207), a plain path.write_text(...) with no mode restriction.
• Contrast the package's own credential handling: _write_private_json() writes credentials.json (client secret + refresh token) with os.open(..., 0o600) and an explicit chmod. The access token gets neither treatment.
• The only hardening is init() chmodding the home directory to 0o700 (line ~191 area) — that does not run on later invocations, and $COLD_STORE_HOME may point at a directory the tool did not create.
• Note the v2 D1 code in the same file is careful to take CLOUDFLARE_API_TOKEN "from the environment only; it is never stored" — the Drive access token deserves the same rule.

Why it matters

A short-lived token is still a live credential: with drive.file scope it can read/modify everything the cold-store app owns — which is the entire archive. The "(no secrets)" label invites copying state.json into places secrets must never go (a synced folder, a debug bundle, a repo).

Acceptance criteria

• The access token is no longer persisted in state.json (keep it in memory only), OR state.json is written with 0o600 permissions via the existing private-write helper and the README stops claiming "(no secrets)".
• README's file-layout table accurately describes what state.json contains.
• Existing tests still pass; a test or check confirms no token value lands in state.json under the chosen design (if in-memory-only).

— filed by the pr-diff-review job (PR #923); triage via the repo-health queue pilot.