-
Notifications
You must be signed in to change notification settings - Fork 11
Description
UX improvement: Docker image requires manual gateway token entry despite nginx auto-auth setup
Expected Behavior
After authenticating with the basic auth credentials (admin/password), the Openclaw Control UI dashboard should automatically connect to the gateway. The nginx reverse proxy is configured to inject the Authorization: Bearer <token> header automatically, so users should NOT need to manually enter the OPENCLAW_GATEWAY_TOKEN.
Actual Behavior
The dashboard loads successfully after basic auth login, but shows "Disconnected" status. Users must manually copy-paste the gateway token into the "Gateway Access" section's "Gateway Token" field and click "Connect" to establish a connection.
Environment
- Image:
coollabsio/openclaw:latest(pulled 2026-01-31) - Docker version: 28.5.1
- Host OS: Linux
- Browser: Chrome
Steps to Reproduce
-
Run the container with
OPENCLAW_GATEWAY_TOKENenv var set:docker run -d \ --name openclaw \ -p 8080:8080 \ -e ANTHROPIC_API_KEY=sk-ant-... \ -e 'AUTH_PASSWORD=MyBigLongPassword' \ -e OPENCLAW_GATEWAY_TOKEN=<generated-token> \ -v openclaw-data:/data \ coollabsio/openclaw:latest
-
Access
http://localhost:8080 -
Log in with basic auth (admin / password)
-
Observe dashboard loads but shows "Disconnected" in the "Snapshot" section
-
The "Gateway Token" field in "Gateway Access" section is empty
-
Must manually paste the token and click "Connect" to get "Connected" status
Evidence
The nginx config IS correctly configured inside the container:
location / {
auth_basic "Openclaw";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:18789;
proxy_set_header Authorization "Bearer <token>";
...
}
Despite this, the Control UI doesn't seem to use the proxied auth header and requires manual token entry.
Impact
This defeats the purpose of having nginx handle authentication. Users shouldn't need to know or manage the OPENCLAW_GATEWAY_TOKEN env var in the UI - it should be transparent.
Possible Cause
The Control UI may be attempting to connect directly to the WebSocket endpoint (ws://localhost:8080) from the browser rather than going through the nginx proxy, bypassing the injected Authorization header.
Suggested Fix
The Control UI should either:
- Trust the authenticated session from nginx and not require a separate gateway token, OR
- Use the proxied connection which includes the Authorization header automatically
Note: This was discovered during testing of the main openclaw Docker image (not the browser sidecar compose setup).