nesquena/hermes-webui

Summary A named custom provider whose GET <base_url>/v1/models probe fails once for a transport-level reason (DNS blip, a slow response past the 5s cap, a throttled retry) gets models_endpoint_error written into the model catalog, and that error is then served from the cached catalog for the full 24 hour TTL (_AVAILABLE_MODELS_CACHE_TTL = 86400.0). Nothing re-probes the endpoint while the cache is warm, and none of the cache's invalidation axes (config.yaml mtime/size, auth.json, .env, plugin dirs) can observe that the endpoint recovered. The user keeps seeing a message that reads like a configuration mistake: Models endpoint unreachable for <provider>; verify base_url. even though the endpoint is reachable and healthy. The only exits are waiting out the TTL, a config/env/plugin change, or an undiscoverable per-provider refresh button. Environment hermes-webui exp-v0.52.448 (WebUI container, /app), agent on 172.18.0.2. Still present on master @ 81e1e7f7 (exp-v0.52.459): reading the

Port preflight follow-ups from the #8112 / #8133 review #8112 (exp-v0.52.455) added a startup port preflight that recognises our own running WebUI on the port before suggesting another one. Greptile flagged two cases it doesn't cover yet. Neither starts a second instance (both fail closed with an error), so they were left out of the release: Windows: WSAEACCES instead of EADDRINUSE (bootstrap.py:734, _check_port_available). A WebUI already listening with SO_EXCLUSIVEADDRUSE, which the WebUI itself uses, makes a second bind fail with winerror=10013 / errno=EACCES rather than 10048. The preflight treats that as a plain bind failure (RuntimeError), so main() skips the existing-WebUI check, and a Windows user who re-runs bootstrap sees a permission error instead of "already running". Fix shape: on 10013 / EACCES, run _already_serving_scheme(host, port). If our WebUI answers, take the already-running path. Otherwise keep the RuntimeError, so genuine permission failures (excluded port rang

Summary On the first start of a freshly created WebUI container, docker_init.bash can exit with Failed to set UID of hermeswebui user if the agent container is writing to the shared ~/.hermes at the same time. The container restarts and the second start succeeds, but anything that waits for health (for example docker compose up --wait) reports the service as unhealthy and fails. !! ERROR: Failed to set UID of hermeswebui user !! Exiting script (ID: 1) usermod: Failed to change ownership of the home directory Steps to reproduce The race is timing-dependent, so this isolates it in a throwaway container instead of the full two-container setup. Start ghcr.io/nesquena/hermes-webui:0.52.441 as root with a shell entrypoint. Create 20,000 files under /home/hermeswebui/.hermes owned by 1024:1024 (the image's default UID). In the background, loop : > /home/hermeswebui/.hermes/x.tmp; mv /home/hermeswebui/.hermes/x.tmp /home/hermeswebui/.hermes/x. Run usermod -o -u 1002 hermeswebui 10 times, res

What happens On the legacy (pre-profile) sidecar layout, a session-archive request for a session owned by another profile can rewrite that profile's sidecar before the request is refused. The pre-dispatch guard loads the target's metadata with Session.load_metadata_only, which on a legacy layout falls back to Session.load. That collapses duplicate partials and saves with a .bak. The route then correctly returns 409, but the foreign sidecar has already changed (observed: 3 messages → 2, plus a .bak). This is on master (exp-v0.52.443) independently of #7826. #7826's own all-profiles lookup had the same shape and now uses a read-only exact-owner query (open_state_db_readonly), but the generic pre-dispatch guard path still does the metadata-only load. Reproduction (from the #7826 release gate, 2026-10-08) Real password auth + CSRF, a default-bound session, and the installed Agent writing two profile databases. A legacy-layout sidecar for a work-profile session in the shared state direct

Composer quota chip: it collapses the footer to icons and squeezes the phone config panel; the "≥1400px" promise isn't implemented Found by the UX gate on #7883 (2026-10-06). This is pre-existing chip behaviour, not something #7883 or #6506 introduces, but both widen the chip's reach (#7883 lights it for OpenCode Go and Command Code users, and #6506 makes it follow the open conversation's provider). The chip is off by default. Desktop. A Playwright A/B on master-equivalent code at 1440×900 with both side panes open: State Footer Model / workspace / profile labels Prompts button Chip hidden full labels visible visible Chip shown (≈54px, e.g. 62%) cf-icons hidden hidden Chip hidden again full labels visible visible The fit routine in static/ui.js (the cf-icons / cf-burger stages around :5432-5474) measures real overflow. The chip's ~54px tips a footer that was already at its limit, so the ambient usage readout survives while the labels saying which model, workspace and