5 ms·

If you wouldn't upload keys to github, why would you trust them to cursor?

• hahahahhaah 9mo ago
  A local .env should be safe to put on your T shirt and walk down times square. Mysql user: test Password: mypass123 Host: localhost ...
  • Imustaskforhelp 9mo ago
    Create a symlink to .env from another file and ask cursor to refer it if name is the concern regarding cursor (I don't knowhow cursor does this stuff)
  • jen729w 9mo ago
    STRIPE_SECRET_KEY="op://81 Dev environment variables/Stripe - dev - API keys/STRIPE_SECRET_KEY" https://developer.1password.com/docs/cli/ https://developer.1password.com/docs/cli/
    • ImPostingOnHN 9mo ago
      How does that prevent an agent from leaking it once it's read into context?
      • jen729w 9mo ago
        Great question. I just checked, and because I launch my entire VSCode with `op run …` (which makes dev life easier), Claude reports that it can read my dev secrets. I could prevent this by running Claude outside of this context. I'm not going to, because this context only has access to my dev secrets. Hence the vault name: `81 Dev environment variables`. I've configured it so that the 1P CLI only has access to that vault. My prod secrets are in another vault. I achieve this via a OP_SERVICE_ACCOUNT_TOKEN variable set in .zshrc. I can verify this works by running: op run --env-file='.env.production' -- printenv [ERROR] 2026/01/15 21:37:41 "82 Prod environment variables" isn't a vault in this account. Specify the vault with its ID or name. Also, of course, 1Password pops up a fingerprint request every time something tries to read its database. So if that happened unexpectedly, I'd wonder what was up. I'm acutely conscious of those requests. I can't imagine it's perfect, but I feel pretty good.