hermes - 💡(How to fix) Fix hermes doctor should warn on insecure .env perms; consider proactive re-tighten on profile load [2 pull requests]

Summary

The recent security work (commit 0ce190be0, "security: enforce 0600/0700 file permissions on sensitive files") correctly ensures that save_env_value() chmods .env files to 0o600 via _secure_file(). This works correctly on the write path.

It does not help .env files that were created before the fix landed and have not been re-written since. Those files keep their pre-fix permissions (typically 0o644 from default umask) silently and indefinitely.

Repro of the gap

# Simulate a pre-fix .env file
$ mkdir -p ~/.hermes/profiles/legacy
$ echo "FAKE_KEY=value" > ~/.hermes/profiles/legacy/.env  # writes at umask default → 644
$ stat -c '%a' ~/.hermes/profiles/legacy/.env
644

# Hermes runs fine, never re-tightens it
$ hermes -p legacy chat        # nothing chmods it
$ hermes doctor                 # no warning

I encountered this in production: six .env files at 0o644 across older profiles (created via the dashboard before the March 9 security fix), undetected until I happened to run a manual perm audit. Single-tenant trust model + /root at 0o700 meant nothing was actually exposed, but the gap matters under the non-root deployment posture suggested in SECURITY.md.

Suggested improvements

Any one of these (in order of cost):

1. hermes doctor warning. Scan ~/.hermes/.env and ~/.hermes/profiles/*/.env; warn if any are group/other-readable. Cheap, surfaces the problem to operators with no behavior change.
2. hermes doctor --fix could chmod them to 0o600 (matching how _secure_file would set them on a fresh write).
3. Idempotent re-tighten on profile/session load. Call _secure_file() on the active profile's .env at startup. Trivial cost; closes the gap without operator action.

Option 3 is the most user-friendly. Option 1 alone would have caught the issue in my case.

Why not a security report

Per SECURITY.md §3.2, this is hardening polish, not a vulnerability — /root at 0o700 prevents the actual exposure on a typical single-tenant install. Filing as a regular issue per the policy's "improvements are welcome as regular issues or pull requests" note.

Environment

• Hermes Agent v0.14.0 (2026.5.16) running on Ubuntu 24.04
• Repro tested against main @ 4ccd141b1 (current as of 2026-05-31)
• save_env_value() correctly produces 600 on fresh writes (verified)
• Pre-existing 644 files are not re-tightened (the gap)