Security/cookie auth hardening

[zvrr]

Description

Related issue:

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 🌐 New site adapter
• 📝 Documentation
• ♻️ Refactor
• 🔧 CI / build / tooling

Checklist

• I ran the checks relevant to this PR
• I updated tests or docs if needed
• I included output or screenshots when useful

Documentation (if adding/modifying an adapter)

• Added doc page under docs/adapters/ (if new adapter)
• Updated docs/adapters/index.md table (if new adapter)
• Updated sidebar in docs/.vitepress/config.mts (if new adapter)
• Updated README.md / README.zh-CN.md when command discoverability changed
• Used positional args for the command's primary subject unless a named flag is clearly better
• Normalized expected adapter failures to CliError subclasses instead of raw Error

Screenshots / Output

[Astro-Han]

Security hardening looks well thought out — token lifecycle (generate → 0o600 write → constant-time verify → cleanup on shutdown), 401 retry in daemon-client, and CDP localhost guard all make sense. Test coverage is good too.

Two observations:

1. The xiaohongshu blob-URL video download fix is a separate concern from the security changes. Might be cleaner as its own PR so each can be reviewed/reverted independently.

2. isSensitiveCookieName uses substring matching (lower.includes(s)), which casts a wide net — e.g. a cookie named authenticate_preference would match on auth. For security redaction that's probably the right tradeoff (better to over-redact), but a brief comment noting the intentional broad matching would help future readers.

[Astro-Han]

Another concrete risk here: CDPBridge.connect() now creates and attaches a target for browser-level CDP endpoints, but that whole block still sits inside the broad try/catch in src/browser/cdp.ts. If Target.createTarget or Target.attachToTarget fails, the exception is swallowed and connect() still resolves a CDPPage.

That means callers can get a seemingly successful connection even though no target session was established, and the first real browser command fails later with a much less obvious error. I think target attach failure should still reject connect(), with only the post-attach niceties like Page.enable staying best-effort.

Another issue in the auth hardening path: src/daemon.ts treats token-file persistence failure as non-fatal (could not write token file), but the daemon still requires Authorization: Bearer <token> on every non-/ping HTTP request. On the client side, src/browser/daemon-client.ts can only discover that token by reading ~/.opencli/daemon.token; if the file is missing or unreadable it simply omits the header.

So a daemon that starts with an in-memory token but fails to persist the file becomes unusable to the CLI: every /status and /command request will get 401, with no real fallback path. I think token-file write failure either needs to be fatal at startup, or the daemon needs an actual compatibility mode instead of logging "non-fatal" and proceeding.