Bug Description
The Docker and xurl docs can lead users to store xurl auth in a location Hermes tool subprocesses will not read.
Docker docs describe /opt/data as the persistent state volume. The xurl docs say tokens persist to ~/.xurl. In Docker, users may reasonably run xurl auth with HOME=/opt/data, creating /opt/data/.xurl.
However, Hermes tool subprocesses can use the isolated subprocess HOME at $HERMES_HOME/home, which is /opt/data/home in the official Docker layout. So Hermes-run xurl commands look for /opt/data/home/.xurl.
The result is a successful OAuth flow followed by Hermes reporting no xurl apps/tokens.
Relevant docs:
Steps to Reproduce
-
Run Hermes in Docker with /opt/data as the persistent data volume.
-
Install or include xurl in the image/container.
-
Authenticate xurl manually with the profile/state root as HOME:
HOME=/opt/data xurl auth apps add my-app --client-id YOUR_CLIENT_ID --client-secret YOUR_CLIENT_SECRET
HOME=/opt/data xurl auth oauth2 --app my-app USERNAME
HOME=/opt/data xurl auth default my-app USERNAME
-
Verify this succeeds:
HOME=/opt/data xurl auth status
-
Check from the HOME Hermes tool subprocesses use:
HOME=/opt/data/home xurl auth status
-
It reports no registered apps/tokens.
Expected Behavior
The docs should make it clear that, for Dockerized Hermes, xurl auth must be created under the same HOME Hermes tool subprocesses use.
In the official Docker layout, that means xurl auth should land at:
/opt/data/home/.xurl
or more generally:
$HERMES_HOME/home/.xurl
Actual Behavior
The OAuth flow can succeed while storing credentials at:
/opt/data/.xurl
Hermes-run xurl commands then fail to see the app/token because they read:
/opt/data/home/.xurl
Affected Component
- Setup / Installation
- Tools (terminal, file ops, web, code execution, etc.)
- Skills (skill loading, skill hub, skill guard)
Messaging Platform
N/A (CLI only)
Debug Report
N/A - documentation/setup-path issue. The behavior is reproducible by comparing xurl auth status with HOME=/opt/data versus HOME=/opt/data/home.
Operating System
Ubuntu 24.04 / Docker
Python Version
N/A - Dockerized Hermes docs issue
Hermes Version
Observed on Dockerized Hermes v0.12-era checkout; related to #12260 subprocess HOME semantics.
Additional Logs / Traceback
N/A
Root Cause Analysis
The root cause is ambiguous documentation around ~/.xurl in Docker.
The xurl docs say tokens persist to ~/.xurl, while the Docker docs describe /opt/data as the persistent state volume. But Hermes tool subprocesses can run with HOME=$HERMES_HOME/home, so the effective ~/.xurl for Hermes-run tools is:
$HERMES_HOME/home/.xurl
not necessarily:
$HERMES_HOME/.xurl
This is related to the broader subprocess HOME behavior discussed in #12260.
Proposed Fix
Clarify this in the xurl skill docs and/or Docker docs.
Suggested wording:
When Hermes runs in Docker, run xurl auth with the same HOME used by Hermes tool subprocesses. In the official Docker layout this is /opt/data/home, so xurl credentials should exist at /opt/data/home/.xurl.
Example:
HOME=/opt/data/home xurl auth apps add my-app --client-id YOUR_CLIENT_ID --client-secret YOUR_CLIENT_SECRET
HOME=/opt/data/home xurl auth oauth2 --app my-app USERNAME
HOME=/opt/data/home xurl auth default my-app USERNAME
HOME=/opt/data/home xurl auth status
Also mention that ~/.xurl for Hermes-run tool commands resolves to $HERMES_HOME/home/.xurl, not necessarily $HERMES_HOME/.xurl.
Are you willing to submit a PR for this?
Not currently.
Bug Description
The Docker and xurl docs can lead users to store xurl auth in a location Hermes tool subprocesses will not read.
Docker docs describe
/opt/dataas the persistent state volume. The xurl docs say tokens persist to~/.xurl. In Docker, users may reasonably run xurl auth withHOME=/opt/data, creating/opt/data/.xurl.However, Hermes tool subprocesses can use the isolated subprocess HOME at
$HERMES_HOME/home, which is/opt/data/homein the official Docker layout. So Hermes-runxurlcommands look for/opt/data/home/.xurl.The result is a successful OAuth flow followed by Hermes reporting no xurl apps/tokens.
Relevant docs:
Steps to Reproduce
Run Hermes in Docker with
/opt/dataas the persistent data volume.Install or include
xurlin the image/container.Authenticate xurl manually with the profile/state root as HOME:
Verify this succeeds:
Check from the HOME Hermes tool subprocesses use:
It reports no registered apps/tokens.
Expected Behavior
The docs should make it clear that, for Dockerized Hermes, xurl auth must be created under the same HOME Hermes tool subprocesses use.
In the official Docker layout, that means xurl auth should land at:
/opt/data/home/.xurlor more generally:
$HERMES_HOME/home/.xurlActual Behavior
The OAuth flow can succeed while storing credentials at:
/opt/data/.xurlHermes-run xurl commands then fail to see the app/token because they read:
/opt/data/home/.xurlAffected Component
Messaging Platform
N/A (CLI only)
Debug Report
N/A - documentation/setup-path issue. The behavior is reproducible by comparing
xurl auth statuswithHOME=/opt/dataversusHOME=/opt/data/home.Operating System
Ubuntu 24.04 / Docker
Python Version
N/A - Dockerized Hermes docs issue
Hermes Version
Observed on Dockerized Hermes v0.12-era checkout; related to #12260 subprocess HOME semantics.
Additional Logs / Traceback
N/A
Root Cause Analysis
The root cause is ambiguous documentation around
~/.xurlin Docker.The xurl docs say tokens persist to
~/.xurl, while the Docker docs describe/opt/dataas the persistent state volume. But Hermes tool subprocesses can run withHOME=$HERMES_HOME/home, so the effective~/.xurlfor Hermes-run tools is:$HERMES_HOME/home/.xurlnot necessarily:
$HERMES_HOME/.xurlThis is related to the broader subprocess HOME behavior discussed in #12260.
Proposed Fix
Clarify this in the xurl skill docs and/or Docker docs.
Suggested wording:
Example:
Also mention that
~/.xurlfor Hermes-run tool commands resolves to$HERMES_HOME/home/.xurl, not necessarily$HERMES_HOME/.xurl.Are you willing to submit a PR for this?
Not currently.