Repository navigation
get_file_contents directory listings put tokenised private-repo download URLs in model context #3748
Description
Describe the feature or problem you’d like to solve
Low-severity hardening suggestion (not a vulnerability report).
In v2.1.0, get_file_contents on a directory of a private repository returns, for every entry, a download_url of the form https://raw.githubusercontent.com/<owner>/<repo>/<sha>/<path>?token=… in the model-visible text. That URL fetches the file with no other authentication for a short time (a few minutes in my tests, and it worked more than once); without the token parameter it returns 404.
The REST contents API itself returns this URL, so the server is passing it through rather than creating it. But for a directory listing the model rarely needs a credential-bearing URL for every file, and it is the one field in the listing that grants access on its own. If an agent is steered by untrusted content (prompt injection) into copying it somewhere public, anyone can fetch that private file for the next few minutes. The marginal risk is small, since a hijacked agent could also read and paste the file, but the URL is a bearer credential the model doesn’t need.
For files of 1 MB or more, get_file_contents also tells the model to use the download URL (pkg/github/repositories.go, the File %s is too large to display … Use the download URL message), which is a reasonable place to keep it.
Proposed solution
- Omit
download_url(or strip itstokenquery parameter) from directory listings by default; callers that need it can already ask for it through thefieldsparameter (download_urlis infileContentFieldEnum). - Keep the explicit download URL for the large-file path, where the model is meant to use it.
Benefit: one less bearer credential in model context and in client logs/transcripts, with no loss of function.
Example prompts or workflows (for tools/toolsets only)
- "List the files in
src/of my private repo" — needs names, paths, sizes, SHAs; not per-file signed URLs. - "Find the config file in this private repo and summarise it" — the agent lists the directory, then reads the file through the tool, never through the raw URL.
- Agent transcripts and MCP client logs that record tool output no longer contain short-lived access tokens for private files.
Additional context
- Reproduced on v2.1.0 (
ghcr.io/github/github-mcp-server@sha256:f6056fc10bfffcc8c81a6417a2e9ca12808647e8dd6049642a4feaadee0e0f8a),--read-only, fine-grained read-only token, against a throwaway private repo in an org I own. Asrc/listing returned 4 entries, all with tokeniseddownload_urls; an unauthenticated GET of one returned 200, the same URL without the token 404. - Found during an independent, AI-assisted review of v2.1.0; reproduced by hand.
Activity
SalyyS1 commentedon Nov 11, 2026
Good catch on
download_urlcarrying the short-lived?token=GHSAT0...query parameter on private repo directory listings. Beyond the credential risk if an agent echoes the URL into an issue comment or external tool call, the directory listing array from GitHub's Contents API also repeats_links,git_url, andhtml_urlon every single entry, which adds significant token overhead on large directories.If anyone wants to strip these before the response reaches the model context today without waiting for an upstream change, we just added URL query-token redaction (
?token=,?access_token=,X-Amz-Signature=) alongside hypermedia_links/*_urlcompaction in mcp-slim (zero-dependency Python 3.10+ stdio proxy):{ "mcpServers": { "github": { "command": "mcp-slim", "args": ["run", "--", "github-mcp-server", "stdio"] } } }On
tools/callresponses it rewrites?token=GHSAT0...to?token=[REDACTED:URL_QUERY_SECRET]and drops the redundant hypermedia links in<1 msbefore the payload enters the LLM context.