Hermes Agent

[alpheus]

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

[andreasdueren]

@alpheus I pushed 0.4.87 which should resolve this

[WiseMetalhead]

Am I right in thinking that Incoming Email in the Cloudron app settings currently doesn't work? Whenever I try to configure the mailbox, I always get these errors in the logs:

Sep 02 17:03:52 2026-09-02 14:03:52,991 ERROR hermes_plugins.email_platform.adapter: [Email] SMTP connection failed: STARTTLS extension not supported by server.

Sep 02 17:03:53 2026-09-02 14:03:53,013 WARNING gateway.run: ✗ email failed to connect

And if I send an email to that address, the agent doesn't respond at all.

Outgoing email works fine, but only if I leave the default settings unchanged after installing the app.

[alpheus]

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

@WiseMetalhead Please update to 0.4.88. It should work now.

[nostrdev]

@andreasdueren we were initially tempted to use cloudron for packaging agents but given the many documented cases of AI breaking out of containers, compounded by the amount of unencrypted internal cloudron comms and ports being available, we backed away

We are now evaluating firecracker on a dedicated machine for agent hosting

Curious what your (and others) position is with regard to the risks of running agents on cloudron containers

[timconsidine]

@nostrdev E2B ? Kata ? Something else ?
(Probably a slippery slope needing its own discuss or off-topic thread, based on your thought-provoking question touching many surfaces).

[nostrdev]

slippery and off-topic indeed - put some iterations into it and made a new topic here. it's a subject that many, if not most, of us are interested in, has probably been well discussed before.

https://forum.cloudron.io/topic/15921/running-ai-agents-on-cloudron-infiltrating-other-containers-and-admin-services

[alpheus]

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

I looked into this further. The missing token is a consequence of upstream Hermes deliberately filtering credentials from subprocess environments, rather than a Cloudron-specific environment issue.

Upstream does offer general environment passthrough, but it explicitly prevents that mechanism from overriding its protected credential blocklist. It also does not currently provide an operator-controlled, per-script credential allowlist for cron jobs.

I’m trying to keep this package as close to upstream as possible, so I won’t be adding a package-specific workaround for that filtering. Maintaining a separate credential-passing mechanism would add complexity and behavior that could diverge from upstream’s security decisions.

A scoped way to give trusted cron scripts access to selected credentials seems like a reasonable upstream feature request. I’d prefer to use an upstream-supported solution if one becomes available, rather than implement a parallel mechanism in the Cloudron package.

@alpheus

[alpheus]

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

[micmc]

I've installed hermes recently and the only issue I have as far as I can see is that the Chat in the Web UI does not seem to work it keeps disconnecting with this message at the top "Chat connection interrupted (code 1006). Reconnecting..." and "WebSocket connection failed".
On the other hand it works well in the app's terminal. So i wonder if this is on purpose for the sake of running in CR?
I've tried a few things even asked hermes how to fix it, but what it suggested did not work. And this is the main line of error message I get in the log

2026-09-15 14:52:01,841 WARNING hermes_cli.web_server: pty refused: origin_mismatch origin=https://hermes-agent.xxxx.xxx bound=127.0.0.1 peer=127.0.0.1

I've looking in this thread but found not the same probem.
Anyone having the same issue or know how to fix it (if fixable in Cloudron of course)

[andreasdueren]

@micmc Thanks for the detailed log. This isn’t intentional, I simply don’t use the web UI and didn’t catch it. I traced it to the dashboard’s WebSocket origin check: the browser connects through the public Cloudron URL, but Hermes only recognizes its internal loopback address. That explains why terminal access works while web chat keeps disconnecting.

While working on this, I found that upstream provides a public-URL setting specifically for reverse-proxy setups. Using it also requires native dashboard authentication, so I’ve implemented the upstream Nous OAuth login flow in the package rather than bypassing the origin check.

The changes are implemented in 0.4.91. I haven’t been able to verify the complete login and browser-chat flow. This will introduce a Nous login and a one-time OAuth client registration for the dashboard, which I documented with the update.

[creative567145]

HI @andreasdueren Hermes dissapeared from https://ca.cloudron.io/
Hope that everything is okay on your side

[andreasdueren]

@creative567145 thanks for bringing this to my attention, this was a problem on the gitlab level which is now resolved.

[creative567145]

Hi @andreasdueren, hope you are having a great day.
Since the Kanban of Hermes was switched from the regular username+password, to CLOUDRON_OIDC

For Hermes instances that have been installed before that change, do you have a clean and easy way on how to make the switch to CLOUDRON_OIDC?

[andreasdueren]

@creative567145 Yes this was an upstream change I needed to implement. Unfortunately the only good way to do that is to create a backup, uninstall, install fresh with OIDC and then roll back your to your old backup

[creative567145]

Thank you @andreasdueren

[micmc]

@andreasdueren Hi Andreas I hope you're doing well mate, it seems like since the last Cloudron update (well, apparently) we have a new connection problem to the web ui via /kanban but also cannot connect from my desktop pointing that

"Nov 03 12:54:39 2026/11/03 17:54:39 [error] 311#311: *343 connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.0.1, server: , request: "POST /kanban/api/auth/ws-ticket HTTP/1.1", upstream: "127.0.0.1/api/auth/ws-ticket", host: "hermes-agent.xxxx.xxx"

Here's the quote from my desktop Hermes which is the best to explain what it seems to go on :

"Your Hermes dashboard backend is unreachable from nginx. The request fails before Hermes can authenticate it—not because your login or API key was rejected.

I checked your public instance:

Endpoint Result
/health 200 OK — reports Hermes API health
/kanban/ 502 Bad Gateway
/kanban/api/auth/ws-ticket 502 Bad Gateway on a GET probe

This narrows the problem to the dashboard/proxy path rather than the whole app being offline.

One suspicious detail: your log shows the upstream as 127.0.0.1/api/auth/ws-ticket, without a port. The package’s current configuration targets 127.0.0.1:9119 for dashboard requests. We need to check your installed configuration before deciding whether the dashboard crashed or nginx is pointing to the wrong destination."

After some recommended verification the following is what it confirms, now I thought I'd report this here before going any further with what Hermes would suggest:

"Nothing is listening on port 9119, despite Supervisor reporting hermes-dashboard as RUNNING. That confirms the dashboard isn’t serving requests; your nginx configuration does specify the expected port.

I checked the package’s service wrapper and found why this can happen: it deliberately stays alive without launching the dashboard when either:

1. No complete OAuth/OIDC login provider is configured, or

2. The app is running in public/restricted mode.

So RUNNING can mean only the wrapper is running—not the dashboard itself. We need to distinguish those cases from a stuck startup.

That said, Hermes container is still reachable and work correctly or so, because when I connect to the terminal it detects the problem and suggest I run hermes pm repair however it cannot work because of Cloudron read only files configuration so here the output:

Ran hermes pm repair; it failed with exit code 1.

Blocked by permissions on:
/app/code/hermes-agent/hermes_cli/tui_dist

That directory is root-owned with mode 700; Hermes runs as cloudron and cannot read it. hermes pm status confirms the dependency sync failed.

The Cloudron app package needs to make this directory and its contents readable/traversable by cloudron, then rerun hermes pm repair. No permissions were changed.

Et voilà ! Hope that helps to look where it seems to fail.

[andreasdueren]

@micmc Hi, thanks a lot for the detailed report, it made this easy to track down.

You found two separate issues, both fixed in package 0.4.117, which is published now:

1. /kanban 502 and the Desktop app not connecting
   Since 0.4.115 the dashboard only starts when a login provider is configured. With Cloudron SSO off there is none, so the wrapper stays up without launching the dashboard. That's why Supervisor showed RUNNING while nothing listened on 9119, and nginx returned a bare 502.

In 0.4.117, /kanban/ now shows a 503 page explaining why the dashboard is off and how to enable it. The API, including ws-ticket, returns a clear JSON error. The log also prints dashboard state: DISABLED (no login provider) at every start.

To actually use the dashboard and the Desktop app, you need one of these:

• Cloudron SSO: Cloudron only lets you choose it at install time. To switch, reinstall with SSO on and restore your data from a backup.
• Nous login: hermes dashboard register from the app terminal.
• Your own OIDC provider: via the HERMES_DASHBOARD_OIDC_* variables.

2. hermes pm repair failing on tui_dist
   That was a real packaging bug: the image created hermes_cli/tui_dist as root with mode 700, so the cloudron user couldn't read it. It also broke the terminal UI. It's fixed, and the build now fails if anything under /app/code isn't readable, so it won't come back. After updating you shouldn't need pm repair at all. The remaining "out of sync (ffmpeg/node/npm/ripgrep)" note is only informational: the image ships its own security-checked versions of those tools.

0.4.117 also brings upstream Hermes v0.22.7 with Node 26. Just update the app in Cloudron.

If it still misbehaves after the update, send me the app log lines around the start (with secrets removed) and I'll have a look.

Cheers, Andreas