News · DiggingBeagle record

GitHub MCP reports show how read-only and approval settings can drift from execution

Recent GitHub MCP issue tests describe noncanonical Boolean values, tool-exclusion typos, misleading destructive metadata and saved installation credentials. The GitHub token still sets the underlying authorization ceiling.

Published
Nov 10, 2026

The report

A GitHub MCP server configured with GITHUB_READ_ONLY=yes could expose write-capable tools even though true and 1 enabled read-only mode. The configuration issue reports 46 exposed tools for the former spelling versus 27 for the latter in version 2.1.0. The underlying GitHub access token still needs write permission for a mutation to succeed, but the agent's apparent tool boundary no longer matches the operator's stated intent.

A rejected value that looked accepted

The issue concerns environment parsing: a familiar affirmative value was interpreted as false without a clear configuration error. A separate excluded-tool-name report describes an unknown tool name silently left active instead of causing startup validation to fail. In both cases, a restrictive intention survived in configuration text but not in the effective tool set.

Another tool-metadata report concerns update_issue_labels, marked destructiveHint=false while replacing the entire label collection. Replacing [c, d] with [a] is not a harmless addition; it removes two existing values. A client relying on that hint to choose a human-confirmation policy could make the wrong decision, although that behavior was not demonstrated across all clients.

Approval configuration can retain credentials

The installation-documentation issue tests a shell command that expands GITHUB_PAT before passing the MCP configuration to Claude Code. The expanded authorization value can be saved literally in process arguments and local configuration instead of being resolved from the environment only when needed. Exposure through shell history depends on the command form and shell; the report does not establish compromised tokens in the wild.

No single item establishes a compromised GitHub organization. Their shared operational consequence is narrower: before giving an agent a task, operators should verify the effective tool inventory, not just the configuration strings; ensure read-only access with an independent read-only token; review what an advertised mutation actually removes; and inspect persistent MCP configuration for expanded credentials. Those checks address different risks and should not be substituted for one another.

Research behind this