No.

I don’t store any secrets locally. I store secrets in AWS Secrets Manager and then I get temporary access keys and set the appropriate environment variables that the AWS CLI and SDKs use automatically to retrieve them.

I usually have three terminal windows open when I’m developing these days - one where I run code that has the environment variable set and my code reads the secrets from Secrets Manager and a terminal window running Claude Code (company reimbursed) and one running Codex using my personal ChatGPT subscription.

In other words, AI agents don’t have access to any secrets.

As far as personal projects, in June will be my 30th anniversary of never writing code that someone isn’t paying me for and my 34th anniversary of never writing code I wasn’t getting paid for or a degree for.

I’m less worried about deliberate exfiltration and more about the structural opacity of these systems. You’re essentially being asked to trust that data boundaries are respected, without any practical way to independently verify those guarantees. Even if the current implementation is sound, the risk surface isn’t static providers, deployment paths, logging practices, and incentives all shift over time. For short-lived or organisational codebases, that trade-off can be reasonable. For personal or long-horizon projects, I’m more cautious. Once intent, context, or structure is absorbed upstream, there’s no meaningful way to claw it back.

undefined

You need to run them sandboxed in some way. Docker is one kind of solution, selinux / apparmor / sandbox-exec is another. Basically, create an environment where .env is not accessible in any way and you don't have to worry about it anymore.

I don't care about it reading the code itself. 90% of my usage is on opensource projects anyway. The other - if I can generate something, then there's no barrier to someone else doing the same - I'm just making applications that do expected things, not doing some groundbreaking research.

tbh im sure they do.

[dead]