Bug Description

When services.hermes-agent.workingDirectory is set to a path outside services.hermes-agent.stateDir, the hermes-agent systemd service cannot write to the workspace. Any attempt fails with Read-only file system.

Root cause: the service unit sets ProtectSystem=strict with ReadWritePaths = [ cfg.stateDir ]. When workingDirectory is a subpath of stateDir (the default ${stateDir}/workspace), it is implicitly writable. When relocated elsewhere (e.g. to a user-visible location for sync/inspection), the sandbox silently locks it to read-only.

The service itself still starts successfully because it does not write to its CWD on startup — the failure only surfaces later when the agent actually tries to create or modify a file in the workspace (e.g. during a task).

Steps to Reproduce

1. Configure hermes-agent with a workspace outside the state directory:

   services.hermes-agent = {
     enable = true;
     stateDir = "/var/lib/hermes";            # default
     workingDirectory = "/some/other/path";   # outside stateDir
     # ... other config
   };

2. nixos-rebuild switch
3. Observe the service starts cleanly.
4. Try to write to the workspace under the same sandbox:

   sudo systemd-run --uid=hermes --gid=hermes \
     -p ProtectSystem=strict -p ProtectHome=no \
     -p ReadWritePaths=/var/lib/hermes \
     --wait --pipe --quiet -E PATH=/run/current-system/sw/bin \
     -- sh -c 'touch /some/other/path/test.txt'

Expected Behavior

workingDirectory should be writable by the service regardless of whether it lives inside stateDir. When a user overrides workingDirectory, the module should include it in ReadWritePaths automatically.

Actual Behavior

touch: cannot touch '/some/other/path/test.txt': Read-only file system

Verified against systemctl show hermes-agent.service:

ReadWritePaths=/var/lib/hermes
ProtectSystem=strict

The workspace path is absent from ReadWritePaths.

Affected Component

Configuration (config.yaml, .env, hermes setup)

Operating System

NixOS 25.11 (Xantusia), systemd 257.9

Python Version

3.11.14

Hermes Version

0.7.0 (pinned rev 8d7a98d2; also present on main at 6116574 — see nix/nixosModules.nix:780)

Relevant Logs / Traceback

touch: cannot touch '/path/to/workspace/test.txt': Read-only file system

Root Cause Analysis

In nix/nixosModules.nix, the native systemd service's hardening block is:

serviceConfig = {
  # ...
  ProtectSystem = "strict";
  ProtectHome = false;
  ReadWritePaths = [ cfg.stateDir ];
  PrivateTmp = true;
};

ReadWritePaths only includes stateDir. When workingDirectory defaults to ${stateDir}/workspace this works because it's a subpath. When the user sets workingDirectory elsewhere (common when they want the workspace visible to file managers, under /home/*, or synced via Syncthing), the path is outside the sandbox write list and becomes read-only.

Proposed Fix

Extend ReadWritePaths to always include workingDirectory. systemd deduplicates the list, so when workingDirectory is a subpath of stateDir the effective sandbox is unchanged:

ReadWritePaths = [ cfg.stateDir cfg.workingDirectory ];

Local workaround (for users hitting this on current versions):

systemd.services.hermes-agent.serviceConfig.ReadWritePaths = [
  config.services.hermes-agent.workingDirectory
];

Co-Authored-By: Claude Opus 4.7