@andreasdueren Hi again!
I updated to the latest version (0.4.89) and I can confirm that HERMES_REDACT_SECRETS is successfully read from scheduled cron jobs!
Thanks for the fix!
Now I have a new but similar issue issue with GITHUB_TOKEN - it is present in the .env (agent confirms that in the chat), but it's not being read in the cron.
Here is the report from the agent:
The cron scheduler runs inside the gateway process. When it spawns the no_agent script, it builds the child env via
build_subprocess_env() → _sanitize_subprocess_env()
which unconditionally strips GITHUB_TOKEN / GH_TOKEN (they're in _ALWAYS_STRIP_KEYS in tools/environments/local.py).
The token is present in /app/data/.hermes/.env (line 436, uncommented, len 93) and in my interactive shell, but it never reaches the cron script's subprocess. This is a design conflict: the backup runner needs the token, but Hermes' secret-scrub policy deliberately removes it from child processes. GITHUB_TOKEN is not registered in config.yaml terminal.env_passthrough, so the scrub isn't bypassed.
Proposed fix (from our side, not yours)
A small wrapper-only code change in our python script that uses github for backup – not a config.yaml change and not a gateway restart.
Current flow:
cron scheduler (sanitized env; token stripped)
→ github_backup_publish.py
→ run_github_backup.py --publish
Proposed flow:
cron scheduler (sanitized env)
→ github_backup_publish.py
→ read /app/data/.hermes/.env internally
→ extract only GITHUB_TOKEN
→ start run_github_backup.py with the existing sanitized env + only GITHUB_TOKEN
After I did this workaround, the github token is successfully read.
My question for you
is this something you could also fix, or I should keep this (or some better) workaround?
Thank you once again for your time!
