Hermes Agent

[creative567145]

Thank you @andreasdueren Andreas for maintaining Hermes. It's a fascinating software.

We are having some difficulty reaching the /kanban/ dashboard.
If possible please forward the steps that you have made to achieve that outcome.

These are our steps:

1. Open a new web browser (allowed third-party cookies)
2. Go at: https://url.com/kanban/
3. Enter the Cloudron user credentials
4. Redirected at: https://url.com/login?redirect=/kanban/
5. Click again: Log in
6. The web browser window refreshes and nothing happens.

From our research, it looks like the Cloudron login system doesn't allow the redirection successfully.

[creative567145]

Looks like that for the past 4 days Andreas has been busy.

Has anybody been successful with the setup of the Kanban dashboard?

[robi]

I have the desktop version on MacOS and it's not on by default.

There are gw commands to initialize it: hermes kanban init but after I got an error from the port it was configured on.

I had the same issue with the app package as you did, the auth doesn't take. Not sure if there's a way to create a local user in the meantime.

There are many other dashboard out there already though, see https://www.bitdoze.com/best-hermes-dashboards/ for their breakdown.

[creative567145]

Thank you @robi , much appreciated

Hi @andreasdueren , here is info that could help you to fix the /kanban/ access
screenshot included

[andreasdueren]

@creative567145 Sorry about that I was traveling, looking into this now.

[andreasdueren]

@creative567145 @robi

Just pushed an app update, this should resolve, the kanban issues.

[msbt]

Not sure where we should post about community packages, so I'm hijacking this topic

First of all, thanks for the package @andreasdueren!

Quick question: did you try/manage to connect to an encrypted Matrix channel? Is it possible that we're missing the mautrix[encryption] package?

[andreasdueren]

@msbt

I haven’t fully tested an encrypted Matrix room yet, but I checked the Cloudron image and it does not look like mautrix[encryption] is missing. The package installs Hermes with the matrix extra, and in the pinned upstream version that resolves to mautrix[encryption]==0.21.0. I also checked the running container: mautrix 0.21.0 is installed, olm imports successfully, and the native _libolm.abi3.so from python-olm is present.

So if E2EE is failing, the next thing to check is probably Matrix E2EE configuration/key state rather than missing dependencies: MATRIX_E2EE_MODE / MATRIX_ENCRYPTION, stable MATRIX_DEVICE_ID, crypto store state, recovery key/cross-signing, and the gateway logs. I used to run hermes (locally, not on cloudron) with encrypted Matrix but ended up migrating to Telegram for features and ease of reliability. Encryption with Matrix for these things is a mess to set up.

[msbt]

@andreasdueren thanks, I finally got it to work with private messages, channels seems to be more difficult. However, I also opted for the telegram option, less hassle

[creative567145]

Thank you @andreasdueren
There is currently 1 small bug with the Hermes package which causes it to be market as: Not responding.
While it is working via the Terminal + via the connected Channels.
This basically causes only the Kanban dashboard to not be accessible.

Details in the screenshot attached

The summarized fix from the screenshot - Quote:
"3. Upstream fix - file a bug / submit a PR for gateway/status.py to recognize hermes-agent.real as valud gateway entrypoint basenames. The fix is the one-line change shown above. This is the real root cause of the gateway being invisible to status/management commands in Cloudron deployments.

Hope that was useful

[creative567145]

For those that need to solve this fast. Here is the PROMPT that can be used (with Claude Opus 4.8)

My Hermes Cloudron container is stuck in a restart loop. The Cloudron
    healthcheck keeps failing with "connect ECONNREFUSED <ip>:8000" and/or
    nginx returns "502 Bad Gateway" on /health, and the container terminates
    and restarts repeatedly. In the boot logs I can see:
    
      => Installing local Chrome runtime for Hermes browser tools...
      ...then it hangs, and earlier logs showed "Ok to proceed? (y)"
    
    Diagnose and permanently fix this. Here is the known root cause and the
    fix that worked before — verify it applies, then execute it:
    
    ROOT CAUSE: start.sh (the container entrypoint, at /app/code/start.sh)
    runs npx agent-browser install to install the local Chrome runtime,
    WITHOUT a non-interactive flag. npx prints an interactive
    "Ok to proceed? (y)" confirmation prompt to install agent-browser. In a
    container there is no TTY to answer it, so npx hangs forever. Because this
    runs in start.sh BEFORE exec supervisord, supervisord never starts, so
    nothing binds port 8000, so the Cloudron healthcheck fails and the
    container restart-loops.
    
    start.sh SKIPS the npx call entirely if a valid chrome binary already
    exists at:  $HERMES_DATA/.agent-browser/browsers/*/chrome
    (HERMES_DATA is /app/data). /app/data is writable and PERSISTS across
    container restarts.
    
    THE FIX (permanent — seed chrome once so start.sh's find succeeds on
    every future boot and never calls the hanging npx again):
    
    1. First check whether you are root or the cloudron user (whoami).
       The install must write to /app/data/.agent-browser as the cloudron
       user so file ownership is correct.
    2. If a hung npx/agent-browser process tree is currently blocking startup,
       identify it (pgrep -af npx / agent-browser) and kill ONLY that subtree.
       Do NOT touch PID 1 or the hermes/supervisor processes.
    3. Run the Chrome install NON-INTERACTIVELY by setting the env var that
       pre-answers the prompt:
         cd /app/code/hermes-agent && \
         HOME=/app/data npm_config_yes=true npx --yes agent-browser install
       (npm_config_yes=true is what bypasses "Ok to proceed? (y)". Run it as
       the cloudron user if you are root: sudo -u cloudron -E env
       HOME=/app/data npm_config_yes=true npx --yes agent-browser install)
    4. Verify a chrome binary now exists:
         find /app/data/.agent-browser/browsers -path '*/chrome' -type f
       and that it is executable.
    5. Ensure the runtime symlink exists:
         ln -sf <that chrome path> /run/agent-browser-chrome
    6. Once chrome is seeded, either restart the container or start supervisord
       so services come up. Watch the /health endpoint until it returns 200
       consistently.
    
    Because /app/data persists, once chrome is seeded there start.sh will skip
    the npx call on every future boot, so the hang cannot recur. Verify the
    gateway binds its port and the healthcheck goes green before you report
    done. Use pgrep/ss to verify processes — do NOT trust `hermes gateway
    status`, which false-reports "not running" in this environment.

And here is the additional info on how we can avoid this if the update is pushed to the package directly (this is the info that I received from Opus, so it needs to be verified):

The seed-chrome approach fixes it durably on that data volume, but if the Cloudron app's data volume is ever wiped/reset, the hang returns on next boot because a fresh /app/data has no chrome.
The truly permanent fix is editing start.sh line 801 to add npm_config_yes=true (and --yes) to the npx agent-browser install call itself — but that file is baked into the container image, not the persistent volume, so it'd need to be changed in the Docker build, not at runtime. The prompt above gives the agent the runtime fix that gets you back online; mention the build-level fix to whoever maintains your Cloudron package if you want it bulletproof against volume resets.

[andreasdueren]

@creative567145

Thanks for the detailed investigation. This was a real package-level status detection issue.

I pushed a fix in package version 0.4.30:

• recognize python -m gateway.run
• recognize hermes.real
• recognize hermes-agent.real
• add regression coverage for those launcher forms

The new app is published and you can update to the newest version. If Cloudron still marks the app as “Not responding” after 0.4.30, please share the Cloudron startup logs and the /health response, because that would likely be a separate health-check/dashboard issue rather than this gateway status bug.