Hermes Agent

[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.