Read the server version from package.json instead of a second literal - #7
Merged
Conversation
serverInfo.version was hardcoded to 0.1.0 in src/server.js while package.json said 0.2.0 and the latest on npm was 0.1.5. Three answers to one question, and the one every client actually saw over the wire was the stale literal: a client talking to any build since 0.1.1 was told it was 0.1.0. Reading package.json removes the second place a version can be written, so the number cannot drift again. package.json is packed into the tarball regardless of the files list, so this resolves in the published package as well as in the repo, which is asserted below rather than assumed. Verified: 38 tests pass; initialize over stdio reports 0.2.0 from the working tree, and 0.2.0 from an extracted npm pack tarball. Greentree-Change-Id: 23b6a95844b9dcf42954fa1ffab1b2e4
las7
added a commit
that referenced
this pull request
Aug 22, 2026
Everything since 0.1.6, which is more than a patch: three tool-surface changes and two defects that made the advertised workflow impossible. - `create_environment(repo:)` clones into `$HOME/work`. It used to run `mkdir -p /work` against a read-only rootfs and fail on every environment this server has ever created. - `expose_port` / `list_ports` / `revoke_port` — an agent can publish what it built. The `tcp` channel their absence was blamed on shipped some time ago. - `pause_environment` — without it, an environment that had run could never be archived (`409 lease_held`), so an agent accumulated them until its plan limit. - `get_environment` reports whether an environment is running, and reads the head snapshot it always claimed to. - Names are generated when you do not supply one. The version now has ONE literal in `src/` (#7) and this commit gives the other two the same treatment. `server.json` carried it twice more — top level and `packages[0]` — and nothing compared them to `package.json`, so a release could publish an npm tarball at one version while telling the MCP registry a different one: a listing that installs something other than what it advertises. A test pins all three, and was checked by breaking only the inner one, which is the half a person reading a diff would miss. 46 pass. Claude-Session: https://claude.ai/code/session_01HtUyvJQEzLGh7MCzKbiaxx Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
serverInfo.versionwas hardcoded to0.1.0insrc/server.js:21, whilepackage.jsonsaid0.2.0and the latest on npm was0.1.5. Three answers to one question, and the one every client actually saw over the wire was the stale literal, so a client talking to any build since 0.1.1 was told it was0.1.0.Reading
package.jsonremoves the second place a version can be written, so it cannot drift again.package.jsonis packed into the tarball regardless of thefileslist, so it resolves in the published package too. That is asserted below rather than assumed.Verified
initializeover stdio from the working tree:npm packtarball, which is the case that would break if the relative path were wrong:Context
Glama's release flow asks for a version, and it was not possible to answer honestly while the server reported one number, the manifest another, and the registry a third. This does not decide which version to release; it just makes the server tell the truth about whichever one is current.
Worth knowing:
package.jsonis at0.2.0and that has never been published. npm's latest is0.1.5. So after this merge the server will report0.2.0whilenpx @reachpad/mcpstill installs0.1.5until someone tagsv0.2.0. That is normal for an unreleased bump, but it is the reason to cut the release reasonably soon.🤖 Generated with Claude Code
https://claude.ai/code/session_011jhbZoyzaAjr1MGrSNMWZK