Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix install.sh: git stash drop fails with 'not a stash reference' when re-running after interrupted install [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#14735•Fetched 2026-04-24 06:14:56
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
josuebustosnjosuebustosn
Participants
alt-glitchalt-glitchjosuebustosnjosuebustosn
Timeline (top)
labeled ×3cross-referenced ×2commented ×1referenced ×1

Error Message

error: 'f98c630a23858a1b4ef8edb501b74df3dbd1bd0d' is not a stash reference

Root Cause

The git stash drop <hash> at the end of the update flow assumes the stash still exists under that exact hash. A prior aborted run can leave that hash stale or orphan the stash blob entirely. The subsequent stash drop has no defense against this.

Fix Action

Fix / Workaround

🛠️ Current workaround

PR fix notes

PR #14749: fix(install): non-fatal autostash drop after apply (#14735)

Description (problem / solution / changelog)

Problem

Re-running scripts/install.sh after an interrupted update could fail at git stash drop "$autostash_ref" with not a stash reference, aborting the whole installer under set -e (see issue).

Fix

  • Run git stash drop with stderr discarded; on failure emit log_warn and continue — changes were already applied successfully.

Tests

tests/test_install_sh_issue_14735.py:

  • bash integration: stale ref after successful apply must not exit non-zero
  • static: scripts/install.sh still contains the guarded drop + issue marker
  • sanity: git stash pop round-trip in a fresh repo

Local run: pytest tests/test_install_sh_issue_14735.py -v -o addopts="-m 'not integration'" (3 passed).

Fixes #14735

Made with Cursor

Changed files

  • scripts/install.sh (modified, +6/-1)
  • tests/test_install_sh_issue_14735.py (added, +102/-0)

PR #14800: fix(install): resolve autostash by stash ref and tolerate stale stash drop (#14735)

Description (problem / solution / changelog)

Summary

Fixes installer update flow when local changes are stashed before git pull: use a stable stash@{n} reference derived from git stash list instead of a raw OID from refs/stash, and avoid aborting the whole install script when git stash drop fails after a successful git stash apply.

Closes https://github.com/NousResearch/hermes-agent/issues/14735

Problem

scripts/install.sh captured the stash tip via git rev-parse --verify refs/stash and later ran git stash drop <oid>. After an interrupted install, that reference may no longer be a valid stash ref for git stash drop, which fails under set -e and stops the rest of onboarding.

Changes

  • scripts/install.sh (clone_repo update path):
    • Include $$ in the autostash message for uniqueness.
    • After git stash push, locate the matching entry in git stash list and use the stash@{n} prefix as autostash_ref.
    • After successful git stash apply, run git stash drop inside a non-fatal branch: log a warning and continue if drop fails.

Verification

  • Manual: re-run installer after interrupting mid-update with a dirty tree; script should not exit solely on stash drop.
  • CI: existing workflows unchanged; change is shell-only in scripts/install.sh.

Notes

Behavior for failed git stash apply is unchanged (still exits with manual recovery instructions).

Changed files

  • scripts/install.sh (modified, +17/-3)

Code Example

git stash → git pull → git stash pop → git stash drop <hash>

---

error: 'f98c630a23858a1b4ef8edb501b74df3dbd1bd0d' is not a stash reference

---

if [[ -d "$HOME/.hermes/hermes-agent/.git" ]]; then
  (cd "$HOME/.hermes/hermes-agent" && git stash clear) 2>/dev/null || true
fi
RAW_BUFFERClick to expand / collapse

🐛 Bug Description

The installer script at scripts/install.sh performs the following sequence internally when updating an existing ~/.hermes/hermes-agent/ repo:

git stash → git pull → git stash pop → git stash drop <hash>

If a previous install was interrupted mid-way (sudo password prompt hung, user Ctrl+C, transient network failure), the stash hash from that aborted run is no longer valid. The final git stash drop <hash> then fails with:

error: 'f98c630a23858a1b4ef8edb501b74df3dbd1bd0d' is not a stash reference

Because users typically invoke the installer as curl ... | bash with set -euo pipefail, the non-zero exit from stash drop aborts the entire install flow, leaving the user's environment half-configured. Hermes is partially installed but key downstream steps (config, dependencies, etc.) never run.

Root cause

The git stash drop <hash> at the end of the update flow assumes the stash still exists under that exact hash. A prior aborted run can leave that hash stale or orphan the stash blob entirely. The subsequent stash drop has no defense against this.

Observed in the wild

Triggered on a fresh Ubuntu 24.04 WSL2 install where sudo apt-get install for Playwright's Chromium deps hung at a password prompt. First run was Ctrl+C'd; second run died immediately at the stash drop step. User was stuck until manually running cd ~/.hermes/hermes-agent && git stash clear.

🔁 Reproduction

  1. Start the installer with an existing ~/.hermes/hermes-agent/ repo present.
  2. Kill the process mid-install (Ctrl+C during any post-stash step).
  3. Re-run the installer. Dies at git stash drop.

✅ Expected Behavior

The installer should not abort on a stale stash reference. Possible fixes:

  • Guard the final git stash drop with || true (benign — the stash pop already succeeded).
  • Run git stash clear at the start of the update flow to wipe orphaned stashes before creating a new one.
  • Replace git stash with a named-ref alternative (e.g. git stash push -m <name> then git stash drop stash@{<name>}) for more predictable cleanup.

🛠️ Current workaround

Users can manually run cd ~/.hermes/hermes-agent && git stash clear before re-running the installer. A downstream team bootstrap script can automate this:

if [[ -d "$HOME/.hermes/hermes-agent/.git" ]]; then
  (cd "$HOME/.hermes/hermes-agent" && git stash clear) 2>/dev/null || true
fi

Environment

  • OS: Ubuntu 24.04 on WSL2
  • Hermes version: current main at time of install (2026-04-23)
  • Install method: curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Notes

This is a relatively common failure mode during onboarding — any transient interruption during the initial install forces the user to manually clear stashes. Most users won't realize this is needed and will bounce off the install.

extent analysis

TL;DR

The installer script can be modified to handle stale stash references by guarding the final git stash drop command or running git stash clear at the start of the update flow.

Guidance

  • Modify the installer script to run git stash clear at the beginning of the update flow to remove any orphaned stashes before creating a new one.
  • Alternatively, guard the final git stash drop command with || true to prevent the installer from aborting on a stale stash reference.
  • Consider replacing git stash with a named-ref alternative for more predictable cleanup.
  • Automate the workaround by adding a script to clear stashes before running the installer, as shown in the current workaround example.

Example

if [[ -d "$HOME/.hermes/hermes-agent/.git" ]]; then
  (cd "$HOME/.hermes/hermes-agent" && git stash clear) 2>/dev/null || true
fi

Notes

The chosen solution may depend on the specific requirements and constraints of the installer script and the Hermes project. It's essential to test any modifications to ensure they do not introduce new issues.

Recommendation

Apply the workaround by adding a script to clear stashes before running the installer, as it provides a safe and effective solution to the problem. This approach prevents the installer from aborting on a stale stash reference and ensures a smooth installation process.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#dependency error#configuration error#environment variable#network issue#logging issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING