/opt/hermes/.venv/bin/uv does not exist — uv is a global binary on the
Hermes base image. Bare `uv` is in PATH; explicit --python targets the venv.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: make kanban patch and Docker build fully failure-safe
- Wrap entire kanban patch in try/except so any error (encoding, permissions,
changed upstream file structure) skips silently instead of exiting 1
- Use errors='replace' when reading kanban_db.py to handle non-UTF-8 bytes
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: resolve Docker build failures by handling library renaming, pinning JupyterLab dependencies, and using explicit binary paths
Install sudo and grant hermes ALL=(ALL) NOPASSWD: ALL so the agent
can run privileged commands (apt install, service management, file
operations) without a password prompt.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Port env-builder from HuggingClaw, adapted for HuggingMes/Hermes vars:
- 8 sections: Core, Backup, Telegram, Terminal, Providers, Cloudflare, Advanced, Custom
- Model catalog with provider/model prefix format (gemini/, anthropic/, openrouter/, etc.)
- Import/export as HUGGINGMES_ENV_BUNDLE base64 or plain .env
- No auth required (useful before GATEWAY_TOKEN is set)
- Dashboard button: "ENV Builder →" beside Open Hermes Agent and Open Terminal
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: use venv python for JupyterLab — system python3 lacks jupyterlab
jupyterlab is installed into /opt/hermes/.venv, not system python3.
start_jupyter() was calling python3 -c "import jupyterlab" which fails
on system python → returned 1 → set -euo pipefail killed start.sh →
container crashed every boot → HF Space stuck in RUNNING_APP_STARTING.
Fixes:
- Use /opt/hermes/.venv/bin/python for the import check and launch
- Change failing return 1s in start_jupyter to return 0 (non-fatal)
- Restore HEALTHCHECK with 60s start-period (was accidentally removed)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
test: disable HEALTHCHECK to diagnose RUNNING_APP_STARTING
HF Space stuck in RUNNING_APP_STARTING despite /health returning 200.
Testing if Docker HEALTHCHECK is causing HF to never flip to RUNNING.
HEALTHCHECK NONE lets HF use its own probe (app_port connectivity).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: health endpoint always 200 so Docker HEALTHCHECK passes on startup
/health was returning 503 when the Hermes gateway hadn't started yet.
Docker HEALTHCHECK uses curl -f which treats 503 as failure, so the
container stayed in "starting" state until the gateway was fully up
(~120s). Combined with start-period=180s, HF Space was stuck at
RUNNING_APP_STARTING indefinitely.
Fix: always return HTTP 200 from /health (gateway status in JSON body).
Reduce start-period to 30s since health server starts in ~2s.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Gateway ready timeout is 120s but healthcheck start-period was 90s.
With heavier image (Chromium + JupyterLab), container took longer
than 90s to become ready causing premature 503 → HF restart loop.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
feat: add JupyterLab terminal at /terminal/ (DEV_MODE=true)
Install JupyterLab in the venv. When DEV_MODE=true and JUPYTER_TOKEN
is set (strong token required — full shell access), start JupyterLab
on port 8888 with /terminal/ base URL. health-server proxies HTTP
and WebSocket (required for kernels/terminals) to JupyterLab.
Usage: set DEV_MODE=true and JUPYTER_TOKEN=<openssl rand -hex 32>
in HF Space secrets, then visit /terminal/.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: install python3-venv and python3-pip for non-root venv creation
Users hit a dependency loop: python3-venv missing → can't create venv →
can't install packages → no root to apt install at runtime.
Installing at build time unblocks standard python3 -m venv usage.
uv venv also works as an alternative (uv is in PATH via profile.d).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: resolve sync timeout with longer timeout and hf_transfer
Default HF Hub read timeout (10s) causes failures on large state uploads.
Set HF_HUB_DOWNLOAD_TIMEOUT=300s and enable hf_transfer for faster
multipart transfers. Install hf_transfer package in Dockerfile.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
feat: install Chromium and enable Hermes browser tools
Install system Chromium with all required display/font dependencies.
Set PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH so Hermes's Playwright picks
up the system binary instead of failing with "Chrome not found".
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
feat: add PATH export to profile and enable secret redaction by default
