Hermes Gateway chat works but enhanced calls show 'Hermes Agent rejected the connection token'

[depre-dev]

Summary\n\nWhen Hermes Workspace is connected to a Hermes Agent gateway, plain chat completions can work through the gateway while the UI still shows:\n\n\nAuthentication required — Hermes Agent rejected the connection token.\nGo to Settings -> Advanced -> Hermes Agent to update your token.\n\n\nThis appears to affect enhanced gateway/dashboard calls, not the OpenAI-compatible chat endpoint.\n\n## Environment\n\n- Workspace image: ghcr.io/outsourc-e/hermes-workspace:latest after the 2026-05-02 rebuild that fixed HermesOnboarding is not defined\n- Hermes Agent image: nousresearch/hermes-agent@sha256:8811f1809971ac558f8d5e311e22fe73dc2944616dda7295c98acb6028f9df08\n- Gateway URL inside Docker: http://hermes-gateway:8642\n- Dashboard URL inside Docker: http://hermes:9119\n- Browser access via SSH tunnel to 127.0.0.1:3000\n\n## What works\n\nGateway health and models work with bearer token:\n\nbash\ncurl -sS http://127.0.0.1:8642/health\ncurl -sS -H "Authorization: Bearer " http://127.0.0.1:8642/v1/models\n\n\nA chat completion through the same key works:\n\nbash\ntimeout 45 curl -sS \\n -H "Authorization: Bearer " \\n -H "Content-Type: application/json" \\n -X POST http://127.0.0.1:8642/v1/chat/completions \\n -d '{"model":"hermes-agent","messages":[{"role":"user","content":"say ok"}],"stream":false}'\n\n\nResponse includes assistant content ok. Workspace chat also returns assistant messages.\n\n## What does not work\n\nThe UI still displays the authentication banner above, even after setting these environment variables to the same gateway key and clearing browser/site data plus Workspace server-side state:\n\nyaml\nHERMES_API_TOKEN: <gateway key>\nCLAUDE_API_TOKEN: <gateway key>\nCLAUDE_DASHBOARD_TOKEN: <gateway key>\nHOME: /tmp/workspace-home\n\n\nThe warning seems to come from enhanced Hermes Agent/dashboard calls rather than chat completions.\n\n## Other fixes needed for this deployment\n\nThe upstream image tried to write below /home/workspace/.hermes and hit EACCES, so setting writable HOME=/tmp/workspace-home avoids unrelated 500s.\n\n## Expected\n\nIf /v1/chat/completions, /health, and /v1/models accept the configured token, the enhanced Workspace calls should either reuse the same token successfully or expose which exact endpoint/token name is failing.

[danrudy33]

I hit a very similar local failure mode, but in my case it does not look like PR #146 was missing.

What happened locally:
- Hermes API (:8642) was healthy
- dashboard (:9119) was healthy
- workspace/Vite (:3000) was healthy
- the breakage came from a stale explicit HERMES_DASHBOARD_TOKEN in the workspace launch environment/config path

That made this look like the old dashboard-auth bug class, but the actual root cause was local token contamination:
- HERMES_API_TOKEN and HERMES_DASHBOARD_TOKEN are not interchangeable
- hardcoding HERMES_DASHBOARD_TOKEN is brittle because the dashboard session token is ephemeral/rotates

What fixed it:
- removed the stale HERMES_DASHBOARD_TOKEN from /Users/(your computer name)/hermes-workspace/.env
- restarted Vite:
  cd /Users/(your computer name)/hermes-workspace && pkill -f "vite dev" && pnpm dev

After restart, workspace recovered and dashboard-backed routes worked again:
- /api/sessions = 200
- /api/skills = 200

So this may be useful as an additional data point for #239:
some “Hermes Agent rejected the connection token” / dashboard-auth-looking failures are not missing upstream separation logic anymore, but stale explicit dashboard-token env contamination in the local workspace process.

[depre-dev]

Thanks, this is a helpful distinction.

We re-tested our containerized setup today against the latest
ghcr.io/outsourc-e/hermes-workspace:latest image.

What improved

• Workspace container is now healthy.
• The previous /home/workspace/.hermes permission issue is gone when the container runs with HOME=/tmp/workspace-home.
• Gateway core chat works through the OpenAI-compatible endpoint.
• Workspace chat can call Averray MCP tools successfully.

So the basic gateway path is working now.

What still fails

The remaining issue appears limited to the enhanced dashboard/session path:

• UI banner: Authentication required — Hermes Agent rejected the connection token
• Sidebar sessions request: dashboard /api/sessions?... returns 401 {"detail":"Unauthorized"}

Difference from the local Vite case

Our setup is Docker Compose, not a local Vite .env, and our overlay currently maps the same long gateway bearer into the Workspace token aliases:

HERMES_API_TOKEN: <gateway bearer>
CLAUDE_API_TOKEN: <gateway bearer>
CLAUDE_DASHBOARD_TOKEN: <gateway bearer>

Given your finding, the explicit dashboard-token alias may be the wrong thing for the dashboard/session route. It looks like Workspace may be sending a bearer token where it should use the dashboard/session flow instead.

Next test on our side

We will try:

1. Remove only the explicit dashboard-token alias from the Workspace container env.
2. Keep the gateway API token aliases for the OpenAI-compatible gateway path.
3. Clear /tmp/workspace-home/.hermes.
4. Clear browser site data for the Workspace origin.
5. Re-test /api/sessions and the UI banner.

Current summary: core gateway/chat/tools are working; the remaining problem is specifically dashboard/session auth when an explicit dashboard token is present in the container environment.

[depre-dev]

Confirmed on our Docker Compose deployment: removing the explicit dashboard-token alias fixed the remaining Workspace auth issue.

What we changed

We stopped passing the gateway bearer as CLAUDE_DASHBOARD_TOKEN to the Workspace container.

We kept only the gateway API token aliases:

HERMES_API_TOKEN: <gateway bearer>
CLAUDE_API_TOKEN: <gateway bearer>

and left CLAUDE_DASHBOARD_TOKEN absent.

Cleanup needed after changing it

After recreating the Workspace container, we also cleared Workspace/browser state:

rm -rf /tmp/workspace-home/.hermes
mkdir -p /tmp/workspace-home/.hermes

Then cleared browser site data for the Workspace origin.

Result

The issue disappeared:

• no more yellow Authentication required — Hermes Agent rejected the connection token banner
• sidebar sessions load again instead of returning dashboard /api/sessions 401
• core chat works
• MCP tool calls work
• full workflow execution works from Workspace
• Slack can read the same Workspace-created run status afterward

So for our deployment the fix was: keep the gateway bearer on the gateway/OpenAI-compatible path only, and do not map it into the dashboard-token alias.

[outsourc-e]

Fixed in PR #250 \u2014 the classifier was matching on bare 'token' keyword which swallowed 'failed to fetch token' as 'gateway_auth_rejected'. Now requires an auth-failure marker (rejected/invalid/expired/missing/etc.) alongside 'token' before mapping to that bucket. Once the upstream chat-stream probe fix in #269 lands too, this whole class of false-positive auth banners should be gone.