Cloudron Forum

@andreasdueren thank you for the response! Makes sense, I will use the current solution until hermes releases the feature.

Once again, thanks for maintenance of the cloudron app!

@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!

@andreasdueren thank you for the fix! I will update hermes in the next few days to the latest version and let you know if it fixed it! Thanks for the fast effort and update!

@andreasdueren hello Andreas!
I have an issue with setting the HERMES_REDACT_SECRETS for scheduled cron jobs. Scheduled cron does phone number extraction and reports it to telegram, but the phone numbers arrive redacted (+49*****1234). If I create a one-off cron and then execute it via hermes cron ... then the redaction doesn't happen (phone numbers are visible).

I think the issue is that the main gateway process doesn't pick up the value that I wrote in the .env file (false), which results in phone numbers being redacted when they are outputted to telegram.
If you want to go into the issue with much more depth, below is the detailed summary from my agent of all the things we tried and all the findings that might be useful.

This happened on HermesAgent app version 0.4.61, but I would guess that the issue still persists.
Thank you for your time and dedication to the project maintenance!

Agent summary

Short version
python -m gateway.run imports agent.redact before gateway.run loads ~/.hermes/.env, so HERMES_REDACT_SECRETS=false arrives too late for its import-time snapshot.
Fixing that alone won't solve it though: the gateway's final outbound delivery call forces redaction regardless, and scheduled cron output passes through both scheduler and gateway redaction layers.

Root causes identified

• agent/redact.py snapshots HERMES_REDACT_SECRETS at import time (_REDACT_ENABLED = os.getenv(...)), so it must be set before agent.redact is imported.
• The Cloudron supervisor's environment= list for hermes-gateway includes HERMES_HOME etc., but not HERMES_REDACT_SECRETS/HERMES_REDACT_PHONES.
• gateway/run.py imports agent modules (which import agent.redact) near the top, but only calls load_hermes_dotenv() much later (~line 1829) — so the .env loads after the snapshot is taken.
• gateway/run.py::_redact_gateway_user_facing_secrets() calls redact_sensitive_text(text, force=True) — this bypasses _REDACT_ENABLED entirely, so security.redact_secrets: false in config.yaml has no effect on this path.
• The phone regex also misses Serbian local format and international numbers with a space after the country code.
• cron/scheduler.py redacts no_agent stdout/stderr independently, then the gateway applies its own forced pass — so scheduled jobs go through two redaction layers.

What we tried

• We tested: security.redact_secrets: false in config.yaml
• HERMES_REDACT_SECRETS=false in .env
• editing supervisord's environment directly (not durable — file is app-owned and replaced on updates)
• a sitecustomize.py early-patch (confirmed _REDACT_ENABLED=False standalone, but scheduled Telegram delivery still redacted due to force=True)
• disabling phone matching + HERMES_REDACT_PHONES=false (still redacted in the real delivery path)