fix: MCP repo/init resolve the forge from a fixed launch dir + global default, not the working directory (second-forge ops break) #390

New issue

Closed

opened 2026-08-17 04:57:07 +00:00 by hexajon · 0 comments

hexajon commented

2026-08-17 04:57:07 +00:00

Owner

What happens

I keep tokens for two forges in the store, keyed by URL. In one session the MCP tools always act on one forge, and I cannot point them at the other.

The CLI handles this correctly. Run from a checkout (or a directory) that belongs to the second forge, it resolves that forge from the origin remote or a workspace scan and uses its stored token. auth whoami from there reports the right forge and Source: workspace scan.

The MCP tools do not. They resolve the forge from the server's launch directory. When that directory has no git signal (empty, no repo, no origin), the chain falls through to the global git config, which is a default forge unrelated to the work. repo list and init then act on that default. Creating under an org that exists only on the other forge fails with a 404.

init accepts a dir, but dir only sets where the local clone lands. It does not move which forge the remote is created on. So there is no per-call way to target the second forge from the MCP surface.

Why it matters

The store already holds both tokens, so both forges are reachable in principle. The gap is selection: the MCP tools choose a forge from a fixed launch directory plus a global fallback, not from the working context. And the repo-management CLI commands are redirected to the MCP tools, so I cannot drop to the CLI to work around it.

Expected

Resolve the forge the way the CLI already does, and the way git does:

From the working directory or the call's target: the enclosing repo's origin host, else a scan of the repos in that directory.
Look the token up by that host (the store is already keyed by host).
No global default. If the forge cannot be resolved, or the directory's repos disagree, fail closed and ask for an explicit forge. Do not silently fall back to a global one.

For init/create (no origin to read yet): resolve from the target directory's neighbours, or accept an explicit forge/owner in the call. Refuse rather than guess.

Repro

Store tokens for two forges, A and B.
Start an MCP session whose working directory is empty (no git repo).
Create a repo under an org that exists only on forge B.
It targets forge A (the global default) and 404s. No per-call flag selects forge B.

#379 (auth login origin-mismatch for env-only forge) and #388 (ambiguous-forge conformance probe) touch the same forge-resolution area from other angles.
This report is the MCP operation surface (repo/init) plus the missing per-call forge target.

## What happens I keep tokens for two forges in the store, keyed by URL. In one session the MCP tools always act on one forge, and I cannot point them at the other. The CLI handles this correctly. Run from a checkout (or a directory) that belongs to the second forge, it resolves that forge from the origin remote or a workspace scan and uses its stored token. `auth whoami` from there reports the right forge and `Source: workspace scan`. The MCP tools do not. They resolve the forge from the server's launch directory. When that directory has no git signal (empty, no repo, no origin), the chain falls through to the global git config, which is a default forge unrelated to the work. `repo` list and `init` then act on that default. Creating under an org that exists only on the other forge fails with a 404. `init` accepts a `dir`, but `dir` only sets where the local clone lands. It does not move which forge the remote is created on. So there is no per-call way to target the second forge from the MCP surface. ## Why it matters The store already holds both tokens, so both forges are reachable in principle. The gap is selection: the MCP tools choose a forge from a fixed launch directory plus a global fallback, not from the working context. And the repo-management CLI commands are redirected to the MCP tools, so I cannot drop to the CLI to work around it. ## Expected Resolve the forge the way the CLI already does, and the way git does: 1. From the working directory or the call's target: the enclosing repo's origin host, else a scan of the repos in that directory. 2. Look the token up by that host (the store is already keyed by host). 3. No global default. If the forge cannot be resolved, or the directory's repos disagree, fail closed and ask for an explicit forge. Do not silently fall back to a global one. For `init`/create (no origin to read yet): resolve from the target directory's neighbours, or accept an explicit forge/owner in the call. Refuse rather than guess. ## Repro 1. Store tokens for two forges, A and B. 2. Start an MCP session whose working directory is empty (no git repo). 3. Create a repo under an org that exists only on forge B. 4. It targets forge A (the global default) and 404s. No per-call flag selects forge B. ## Related - #379 (auth login origin-mismatch for env-only forge) and #388 (ambiguous-forge conformance probe) touch the same forge-resolution area from other angles. - This report is the MCP operation surface (repo/init) plus the missing per-call forge target.

hexajon referenced this issue from a commit

2026-08-17 11:03:51 +00:00

fix(config): resolve the forge from the working context, not a stale global default

hexajon referenced this issue from a pull request that will close it,

2026-08-17 11:03:51 +00:00

fix(config): resolve the forge from the working context, not a stale global default #406

hexajon closed this issue

2026-08-17 11:03:53 +00:00

hexajon referenced this issue

2026-08-17 15:52:04 +00:00

fix: commit author/committer come from the global git identity, not the target repo; verify identity + signing before push #425