Hermes Agent

[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