Hacker News Reader

Comment by philbo | Hacker News Reader

Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anything listed in your .gitignore files. I only noticed it because I have separate read scopes for project files, ignored files, dotfiles and external files, so the latter three always prompt me for approval.

I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...

(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ )

View on HN

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

1Password CLI has a similar feature I use all the time and share with the team.

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.

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.

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.

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.

Reply on news.ycombinator.com