hermes - 💡(How to fix) Fix hermes update crashes with `ValueError: too many values to unpack (expected 2)` during post-pull dependency install

Summary

hermes update crashes with ValueError: too many values to unpack (expected 2) immediately after the "Updating Python dependencies..." step on a clean managed install. The git fetch and pull phases complete successfully; the crash is in the post-pull Python dependency install path.

Environment

• Hermes Agent: v0.15.1 (2026.5.29), starting 146 commits behind origin/main
• OS: CachyOS Linux (Arch-based)
• Python: 3.11.15 (uv-managed venv at ~/.hermes/hermes-agent/venv)
• uv: 0.11.19 (managed at ~/.hermes/bin/uv)
• Install method: managed installer (single-line curl install)

Reproduction

1. Start on a Hermes install 146 commits behind origin/main.
2. Run hermes update.
3. Observe crash at the dependency install step.

Observed output

⚕ Updating Hermes Agent...

→ Discarded npm lockfile churn (1 file(s))
→ Fetching updates...
→ Found 146 new commit(s)
  ✓ Pre-update snapshot: 20260605-092434-pre-update
→ Pulling updates...
  ✓ Cleared 81 stale __pycache__ directories
→ Updating Python dependencies...
Traceback (most recent call last):
  File "/home/colin/.hermes/hermes-agent/venv/bin/hermes", line 10, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/colin/.hermes/hermes-agent/hermes_cli/main.py", line 15661, in main
    ),
    ^^^
  File "/home/colin/.hermes/hermes-agent/hermes_cli/main.py", line 9772, cmd_update
    if "Could not resolve host" in stderr or "unable to access" in stderr:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/colin/.hermes/hermes-agent/hermes_cli/main.py", line 10237, _cmd_update_impl
    # time (platform-specific optional deps, ideallyInert annotations, etc.),
        ^^^^^^^^^^^^^^^^^^^^^^^
ValueError: too many values to unpack (expected 2)

Note: the line number reported (10237) lands inside a comment in _cmd_update_impl, which suggests Python is reporting the line where the offending call expression was defined rather than the actual failing statement — the real crash is in a function called from around that area.

Workaround

After the crash, the working tree is already fully updated (git log shows the 146 new commits on main). Running the post-pull install steps manually finishes the update successfully:

cd ~/.hermes/hermes-agent
source venv/bin/activate
uv pip install -e ".[all]"          # installs the updated package metadata
python -c "from hermes_cli.main import _update_node_dependencies, _build_web_ui, _refresh_active_lazy_features, PROJECT_ROOT; _update_node_dependencies(); _build_web_ui(PROJECT_ROOT / 'web'); _refresh_active_lazy_features()"

After this, hermes version reports Up to date and hermes update on a clean tree correctly prints ✓ Already up to date! — confirming the post-pull code is healthy and the crash is specific to the first run that actually has to install updated deps.

Suspected root cause

The 146-commit window being pulled in included several fix(update) commits that were subsequently reverted:

9ab9c923d docs(dashboard): clarify auth provider suitability + registration across dashboard/Docker/Desktop docs (#39633)
b0d234f06 fix(cron): don't crash on `cron list` when a job's repeat is null
c8e80cd0b fix(update): require managed marker before destructive clean
ad69d3edc fix(terminal): guard os.getcwd() against a deleted CWD
b1e399de9 fix(update-check): stop reporting phantom "N commits behind" inside Docker (#39559)
...
4eca569bf fix: temp for update
275f90a1d Revert "fix(update): stop stash/restore from clobbering desktop source on managed clones (#38542)"
4d498ac56 Revert "fix(update): require managed marker before destructive clean"

The 4eca569bf fix: temp for update commit also lands an unfinished stub function in hermes_cli/managed_uv.py:

def rebuild_venv(uv_bin: str, venv_dir: Path, python_version: str = "3.11") -> bool:
    True # dont remove me. ask ethernet

The function body is True (a statement, not a return), the function is never called from anywhere in the tree, and the file is missing its trailing newline. Combined with the active revert churn, the post-pull install path appears to be in an inconsistent state that breaks unpacking somewhere in the dependency install call chain (_install_python_dependencies_with_optional_fallback / ensure_uv / update_managed_uv).

Suggested next steps

• Add a smoke test that exercises the full hermes update code path on a fixture repo with a known number of upstream commits behind, so a regression like this gets caught before merge.
• Avoid landing "temp" commits like 4eca569bf to main — they introduce half-finished functions and the "dont remove me. ask ethernet" comment suggests there's a follow-up intent that should land in the same PR.
• Consider a hermes doctor check that detects the "revert storm" pattern in recent git history and warns the user that the install path may be unstable.