github-mcp 4.2.0: vendor bash-mcp-sdk v5.0.0, and run only the tools a server declares

[Martin Bens (SpiGAndromeda)]

Vendors shared/mcpserver_core.sh from shopwareLabs/bash-mcp-sdk v5.0.0, up from v3.0.0, and fixes what bumping it surfaced. Releases the plugin as 4.2.0.

A server ran tools it never declared

The largest change here, found while checking the bump against the open issues.

A tools/call resolves to a shell function by name, so a server could run any tool_* function it had sourced, declared or not. api.sh, label.sh and project.sh are shared by both servers and each carries tools the other does not declare. That put label_add, label_remove, project_item_add, project_status_set and api — which takes any HTTP method — on the read server, which is always active and needs no configuration.

enable_write_server gated what tools/list advertised and nothing else. All five ran against the authenticated gh CLI whether or not the write server was enabled.

An undeclared tool also has no schema, and argument validation treats a missing schema as nothing to check, so each of them ran with unvalidated arguments. That validation is what #3 identifies as the only thing keeping tool arguments away from the unguarded numeric comparisons in _gh_post_process; without it, a crafted max_lines reaches bash arithmetic evaluation and executes a command inside the server process, which holds the user's gh credentials.

_gh_unset_undeclared_tools removes every sourced tool function the running server's tools list does not name. It derives the permitted set from that list rather than a hardcoded roster, so a tool added to a shared lib cannot reopen the gap. An empty tools list leaves nothing callable, which is what now makes a disabled write server inert rather than merely quiet about what it can do.

This closes the reachable half of #3. The issue stays open for its own fix: the guarantee still rests on 45 schema declarations that nothing downstream re-checks, and a future edit dropping a type reopens it silently.

Dependency floors are now enforced

v5.0.0 checks bash 4.1+ and jq 1.7+ when the file is sourced, and refuses to start below either. Both were already the protocol layer's documented requirements and nothing checked them: below the bash floor a server died with {_MCP_LIFELINE_FD}: not found before writing a byte of JSON-RPC, which a host reports as nothing more than a failure to start; below the jq floor it ran while silently skipping part of the argument validation its own schemas declare.

This stops servers that start today. macOS keeps bash 3.2 at /bin/bash and no install replaces it, so a Mac needs a newer bash ahead of /usr/bin on the PATH the MCP host launches the server with — and a host started from the desktop reads no shell profile, so that is not necessarily the PATH your terminal has. A refusal names the requirement, the version found, and the install command for the platform.

README listed bash 4.0+, which was never the requirement, and gave no jq version at all. Both files now carry the floors, and SETUP.md's byte-identical copy under plugin-setup is re-synced.

Also fixed

Downloads are written atomically. repo_file and search_code with download_to redirected gh straight into the destination, so a call ending partway left a truncated file indistinguishable from a complete one. Cancellation makes that reachable — from v4.0.0 a cancelled call has its tool process group signalled, where the command previously ran to completion regardless. Both sites write to a .partial sibling and rename once gh exits cleanly. Two older defects go with it: _gh_download_file redirected stderr into the file as well, so a failed download wrote the API's error text to disk as the file's contents, and repo_file deleted whatever already sat at the destination when a download failed.

The disabled write server no longer writes its own tools list. The mktemp template placed its placeholder mid-name, so mktemp took it literally and every server on the machine shared one fixed path; the cleanup ran from an EXIT trap that run_mcp_server replaces, so it never ran at all. Harmless under v3.0.0, where a removed tools list read as an empty one — but from v4.0.0 an unreadable tools list answers -32603, so anything removing the file turned a disabled write server into one that failed every initialize. A shipped mcp-server-gh/tools-empty.json replaces it.

What the bump brings on its own

• A malformed request no longer ends a server. A line carrying more than one JSON document, a document that is not an object, a tools/call whose params is not an object, and a request whose id is neither a string nor an integer were each fatal with no response, leaving every later request unanswered. Each is now answered.
• Cancelling a tool call stops the work. notifications/cancelled was ignored, so a cancelled run_logs or search_code ran its gh command to completion. No plugin change was needed for this.
• A configuration or tools file that cannot be read is refused rather than reported as an empty one.