API keys die of exposure: not only “evil hackers,” but accidental publication. Your job is to pick storage that matches your threat model — for Coffee’s browser demos, that often means local browser storage you control, not a Slack thread.
Never commit keys to Git. Bots scan public repos within minutes. Use environment variables on servers, or .env files that are gitignored. For static frontends, keys that ship to the browser are visible to users — treat them as “public” or use a backend proxy.
Support threads and screen shares are leak vectors. Prefer rotating a key after it appeared somewhere uncontrolled.
KEY1-CORE stores credentials in your browser profile (IndexedDB, with legacy mirrors for older surfaces). That is appropriate for local-first Coffee tooling: data is not uploaded to Coffee Computer’s servers from that page by design — but anyone with physical access to your machine or a copied profile could still read them. Align expectations with “my laptop, my profile.”
Not a substitute for a secrets manager in a shared production fleet — but a coherent place for Coffee web surfaces to read the same keys you already chose to keep in-browser.