Running mcp-server-git with uvx gives full disk access/--repository param is ignored

Describe the bug
mcp-server-git does not restrict repo paths to the repo specified.

The docs have this code block:

"mcpServers": {
  "git": {
    "command": "uvx",
    "args": ["mcp-server-git", "--repository", "path/to/git/repo"]
  }
}

Which would imply you are limiting the mcp server to that repository but in practice the only thing --repository is used for is this (link]:

if repository is not None:
	try:
		git.Repo(repository)
		logger.info(f"Using repository at {repository}")
	except git.InvalidGitRepositoryError:
		logger.error(f"{repository} is not a valid Git repository")
		return

After that codeblock it doesn't seem to be used. All the commands take a "repo_path" which can be anywhere on your machine. Coupled with "git_init" you can effectively read any file on the computer as long as you have the permissions to init a git repo.

If this is expected behavior then maybe it would be nice to add something to the docs about it.

To Reproduce
Steps to reproduce the behavior:

mkdir reproduce-repo
cd reproduce-repo
git init
npx @modelcontextprotocol/inspector uvx mcp-server-git --repository "path/to/your/repo"
Open Browser and go to http://localhost:5173
Select "STDIO" and click Connect
List Tools
Run the git_status tool and enter a path different from what you passed in to the --repository flag

Expected behavior
One or more of the following:

Either a clear message that this tool has full access and should only be use with Docker

or

Allow for limiting the MCP server's access

Ideally you'd supply a base path (or paths) and it would be able to read/write to any repos in that path to allow for features like #188 (on purpose).

Logs
N/A

Additional context
N/A

I am not sure if this is related, but when running on a mac in uvx the repository passed in on the command line doesn't propagate through to the repo_path and it seems like it should by default?

This pull request resolves the issue, please take a look!

@sparesparrow

Hardening + Documentation Framing (per Runtime Architect analysis 2026-07-25)

Following up on this 17-month-old issue (#604) with a more precise classification.

Evidence

I reproduced this with runtime exploitation against mcp-server-git==2026.7.10 (latest PyPI release as of 2026-07-10) using the documented python3 -m mcp_server_git startup command (no --repository flag passed).

Actual MCP client request + response captured:

Request	Response	isError
`git_status` arbitrary `repo_path`	"Repository status: On branch master, ..."	False
`git_log` arbitrary `repo_path`	Full commit metadata returned	False
`git_show HEAD` arbitrary `repo_path`	Diff with file content (`+secret_file_content_DO_NOT_LEAK`)	False

So bypass is real. Full PoC in workspace (reproducible in <5 min).

Classification: Hardening + Documentation (NOT GHSA/CVE)

After Runtime Architect review, this should be classified as security hardening + documentation issue, NOT a CVE-grade vulnerability:

No security boundary explicitly violated. The project's README documents repo_path as a tool INPUT. Commit a37158b explicitly preserves this behavior as "backward compatibility when --repository is not set." The validate_repo_path() gate is OPT-IN — only active when --repository is set.
Operator expectation gap amplifies impact. Most operators using uvx mcp-server-git (Claude Desktop, Cline, etc.) intuitively assume "Git server" means "works on intended repo" — but default config permits any Git working tree on host. This gap is a real concern, but it's design+doc issue, not boundary violation.
Existing partial CVE exists. CVE-2025-68145 / GHSA-j22h-9j4x-23w5 covers the --repository IS set branch. This issue (#604) describes the same code path but from the angle that --repository is ignored when not set — architecturally the same root cause family.

Suggested hardening (instead of CVE filing)

Either of these would close the gap:

Option A — Document explicitly:

README: "If --repository is not provided, the server will accept any git working tree path
passed via the repo_path tool argument. For production deployments with untrusted MCP clients,
set --repository to restrict access."

Option B — Change default to safe:

# server.py line 308 — change signature to require or default safely
async def serve(repository: Path | None) -> None:
    if repository is None:
        # Default to current working directory OR fail-loud with clear message
        repository = Path.cwd()
        # OR raise SystemExit("mcp-server-git requires --repository <path> in production deployments")

PR #630 (already open 17+ months) implements Option B via PathValidator — that would close this fully.

Why NOT GHSA/CVE

No security boundary was promised in the user-facing spec that the runtime behavior violates
Maintainer explicitly preserved behavior with documented rationale
Fix channel is maintainer discussion + doc update, not CVE database
Filing a CVE here would likely be rejected as "intended behavior, configure properly"

Runtime evidence retained

The runtime PoC is preserved at /tmp/poc-mcp-server-git/exploit.py for operator self-assessment. If README is ever updated to promise path restriction, the classification flips to vulnerability (CWE-862 Missing Authorization) and a GHSA filing would be appropriate.

Cc: @sparesparrow (PR #630 author), @taylorwilsdon (related upstream pattern via GHSA-j22h-9j4x-23w5)

fix(git): sandbox validate_repo_path to cwd when --repository is unset

Closing: superseded by the v2 release.

Thank you for reporting this, and apologies for the long wait for a response.

Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. On v2/main --repository confines every tool call's repo_path to that repository (validate_repo_path), and the README documents that without --repository access follows each call's repo_path.

This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.

If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see CONTRIBUTING.md.

Thanks for taking the time to report it.

Navigation Menu

Repository navigation

Running mcp-server-git with uvx gives full disk access/--repository param is ignored #604

Hardening + Documentation Framing (per Runtime Architect analysis 2026-07-25)

Evidence

Classification: Hardening + Documentation (NOT GHSA/CVE)

Suggested hardening (instead of CVE filing)

Why NOT GHSA/CVE

Runtime evidence retained

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Running mcp-server-git with uvx gives full disk access/--repository param is ignored #604

Description

Activity

bgintzairspace commented on Feb 7, 2025

sparesparrow commented on Feb 15, 2025

ahmadfardan464-cmyk commented on Jul 25, 2026

Hardening + Documentation Framing (per Runtime Architect analysis 2026-07-25)

Evidence

Classification: Hardening + Documentation (NOT GHSA/CVE)

Suggested hardening (instead of CVE filing)

Why NOT GHSA/CVE

Runtime evidence retained

cliffhall commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions