It’s fun. You should try playing it instead of judging by heuristics.

1. Make tests 2. Commit them 3. Proceed with implementation and tell agent to use the tests but not modify them

It will probably comply, and at least if it does change the tests you can always revert those files to where you committed them

Are there really no ways to control read/write permissions in a smart way? I've not had to do this yet, but is it really only capable of either being advisory with you implementing all the code, or it having full control over the repo where you just hope nothing important is changed?

You could probably make a system-level restriction so the software physically can't modify certain files, but I'm not sure how well that's going to fly if the program fails to edit it and there's no feedback of the failure.

You can use a Claude PreToolUse command hook to prevent write (or even read) access to specific files.

With this approach you can enforce that Claude cannot access to specific files. It’s a guarantee and will always work, unlike a prompt or Claude.md which is just a suggestion that can be forgotten or ignored.

This post has an example hook for blocking access to sensitive files:

https://aiorg.dev/blog/claude-code-hooks#:~:text=Protect%20s...

No. I don't want the mental burden of auditing whether it modified the tests.

Then, run the agent vm-sandboxed, with tests mounted as a read-only directory, if your directory structure allows it.

Or, less securely, hash the tests and check the hash with a hook, post tool use. Or a commit hook.

I really don’t see the connection. A$AP isn’t a noob

Code is rusty ankles and ashy kneecaps.

I believe the article reached the same conclusion you did

> Cleartext signatures considered harmful

Really? To me it seems that what’s really harmful is assuming a long string of high entropy hex bytes is a valid signature.

Both detached signatures and cleartext need to be run through verify, so what gives?

Does gpg not error when the post-verification output file doesn’t match the cleartext? That sounds like a bug in gpg

It appears that by default, gpg doesn't output the signed text at all when verifying a cleartext signature. It does not appear to check for or warn about extra content before or after the cleartext text and signature. It strictly interprets the start/end lines, and won't warn or fail for malicious ones. It does not appear to accept comment headers in the signed message, but does accept them in the signature, which means that a user might think an arbitrarily long message in the signature is actually signed.

These all seem like flaws in gpg and the standard.

Thanks, I’ll try this :)

You can’t separate layout and design from typeface selection.

But yes I agree content must come first. Typeface probably comes second!

Holy fuck they actually built Smart Pipe[1]

1: https://youtu.be/DJklHwoYgBQ?si=bSRE2lOqwwm1Q_D9

I'm convinced whatever Torment Nexus we can think of will get built.

Rule 34(B)?

Now's the time to get on board so that, when they launch the social network, you can be a top influencer just like Scout

#itsmyanus