Secrets should not be inside a versioned directory nor usually readable by the process that uses them in production. They should be only in the environment (e.g. by root only readable init config).

In development you should not be using the real production values.

i use sops

Encrypt: sops encrypt --input-type dotenv --output-type dotenv .env > secrets.enc.env

then rm .env

You can then run your script/dev with: sops exec-env secrets.enc.env 'docker xxxx' (it will ask you for your password, or touch-id to decrypt the secrets)

I like this because this way the .env doesn't sit in the directory at all, and is only passed to your dev environment and stays in it while it's running

Decrypt back to a file (if you ever want that): sops decrypt secrets.enc.env > .env

---

Well ofc, any agent can do docker inspect to get all those env vars, but atleast reading the dotfiles won't do anything

you can also edit the file with: sops --input-type dotenv --output-type dotenv secrets.enc.env

It is no longer surprising to me that my cursor acts as if it does not recognize the .env file, and while I am editing it, it does not give inline suggestions;

however...when it is debugging problems or responding to questions about the code, it will just say it read my env file and found xxx environment variables as a verification step, or sometimes it will even mention that I need to uncomment some environment variables in the env file, which makes the whole deal about security feel iffy giffy....

They act exactly like how I would act if I were dropped into someone's machine and tasked with accomplishing a goal "at all costs". Hunting around for context to understand what I'm dealing with and to an extent profiling the previous user for their workflows and competency.

I tested GLM while working on some android app, the agent had adb access to the device. It suddenly went to the Gallery and started scrolling around, taking screenshots, lol. A friend had a similar experience with GLM where it would for no very clear reason start snooping through the filesystem.

Haven't used it after that.

Grok does or did the same thing, this is embarrasing

Just my thoughts on the site:

It's good that the objective is to have the model work as a helper, but that's what everyone can already do with CC or Codex as long as you don't ask to "write this entire x thing". It's also what a billion other, often vibecoded, harnesses claim they can do.

Why should I use yours, which also forces me off my existing subscriptions? Maybe it's (mostly) handwritten, so it's mindful efficient code instead of slop, and each adjustment was made through trial and error with current models? maybe it IS slop but at least you have a unique feature? and so on and so forth.