Point the skills root at --data-root, not at the running bundle - #687
Merged
Conversation
installedPath resolves against the bundle that is executing. That is right when the bundle is the installed one, and wrong the moment it is not: running a checkout's dist/ while --data-root pointed at the real installation wrote the checkout's path into a permanent Hermes config. The damage is not a missing file today. It is a config bound to a tree that will be deleted or switched, after which the skills vanish while mcp_servers stays valid -- the half-configured state #684 was about, reached through a different door. The same wrong-name refusal would follow. So when the data root holds this version's skills, that is the answer. The bundle's own location stays as the fallback for the case it was always correct for, an installation invoking itself, and an explicit --skills-dir still wins. Found while verifying #684 against a real Hermes profile, which is the only place it could have been found: every test until now supplied skillsDir explicitly and so never exercised the derivation. Verified by restoring the old resolution -- the data-root case fails. Limit: a permanent config never records a path that belongs to one invocation Blast: module Undo: easy Certainty: firm Provenance: authored Record-Id: r-686skil
CommitLore — record lintTrailers: clean — 1 commit in Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
Merged
MongLong0214
added a commit
that referenced
this pull request
Aug 15, 2026
Five fixes have been sitting on main since v1.0.0 and none of them has reached
anyone. They are all defects at the install and distribution boundary, and that
boundary has exactly one delivery mechanism: a release.
#683 the release workflow failing on a release that already exists
#684 hermes install refusing the config it wrote
#687 the skills root taken from the running bundle instead of --data-root
#688 an installed plugin treated as a reason to stop rather than upgrade
#690 claude-code wired by nothing, in neither hosts nor notDetected
Measured rather than assumed: re-installing with main's install.sh still left the
plugin cache at 0.8.0 and claude-code out of both lists, because the enumeration
that #690 fixed is compiled into the binary being installed -- and that binary is
v1.0.0.
dist is unchanged and the canonical digest is identical to before the bump. The
version is read from package.json at runtime rather than compiled in. Rebuilt
through the canonical builder and verified rather than assumed, the same as
v1.0.0.
Thirty-eight pins across nine files. The installers and READMEs carry the tag in
URLs that resolve only once the tag exists, so this is one commit and the tag
goes on it.
This is the first release cut under release-gate 6c, which asks for an upgrade
over the previous version rather than a fresh install. The five fixes above are
why that section exists.
Limit: a distribution-boundary fix reaches nobody until it is released
Blast: system
Undo: costly
Certainty: firm
Provenance: authored
Record-Id: r-rel101
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #686.
installedPathresolves against the bundle that is executing. That is right whenthe bundle is the installed one, and wrong the moment it is not:
--data-rootwas supplied and the MCP entry honoured its wrapper. The skillsroot did not.
Why this is worse than a wrong path
The config is now bound to a tree that will be deleted or switched. When it goes,
the skills vanish while
mcp_serversstays valid — the half-configured state#684 was about, reached through a different door, and the same misnamed refusal
would follow.
The resolution
When the data root holds this version's skills, that is the answer. Otherwise the
running bundle's location, which is the case
installedPathwas always correctfor — an installation invoking itself, which is most runs. An explicit
--skills-dirstill wins.Why no test caught it
Every existing Hermes test supplies
skillsDirexplicitly, so the derivation wasnever exercised. It was found by installing v1.0.0 against a real Hermes profile
while verifying #684 — the only place it could have been found.
test/hermes-skills-root.test.tscovers both directions. Negative control:restoring the old resolution makes the data-root case fail.
Canonical artifact
424da7f4.