API tools: dir= targeting — file issues against any locally-cloned, repo-scoped-authed repo #59

New issue

Closed

opened 2026-07-14 15:49:49 +00:00 by hexajon · 3 comments

hexajon commented

2026-07-14 15:49:49 +00:00

(Migrated from codeberg.org)

The git plane already resolves forge + credentials per-repo: madt_fetch / madt_worktrees / madt_commit / madt_finish accept dir= on a foreign clone and push / open PRs against that repo's own remote using its per-repo credentials (the documented foreign-repos flow). The issue/API plane does not: madt_issues takes only owner_repo=, resolved against the MCP server's launch-bound forge.

Consequence: a session whose server is bound to forge A cannot file a bug against a repo cloned locally from forge B, even though the local clone carries working credentials in its repo scope. Concrete case (2026-07-14): from a Gitea-bound session I needed to file mad-tea bugs; mad-tea's tracker is on Codeberg (a correctly-authed local clone exists), owner_repo= 404s on the bound server, and the CLI fallback is correctly blocked by the CLI-steering hook (ADR 0009) — leaving no sanctioned path at all. (I had to file these two issues by hand.)

Ask: if a repo is cloned locally and correctly authed inside that repo's scope, any agent/user on the system should be able to file a bug against it. Give madt_issues (and the sibling API tools — prs, labels, milestones, comments) a dir= form that resolves server + auth from that clone's remote/credential scope, mirroring what the git plane already does.

The git plane already resolves forge + credentials per-repo: `madt_fetch` / `madt_worktrees` / `madt_commit` / `madt_finish` accept `dir=` on a foreign clone and push / open PRs against **that repo's own remote using its per-repo credentials** (the documented foreign-repos flow). The issue/API plane does not: `madt_issues` takes only `owner_repo=`, resolved against the MCP server's launch-bound forge. Consequence: a session whose server is bound to forge A cannot file a bug against a repo cloned locally from forge B, even though the local clone carries working credentials in its repo scope. Concrete case (2026-07-14): from a Gitea-bound session I needed to file mad-tea bugs; mad-tea's tracker is on Codeberg (a correctly-authed local clone exists), `owner_repo=` 404s on the bound server, and the CLI fallback is correctly blocked by the CLI-steering hook (ADR 0009) — leaving no sanctioned path at all. (I had to file these two issues by hand.) Ask: if a repo is cloned locally and correctly authed inside that repo's scope, any agent/user on the system should be able to file a bug against it. Give `madt_issues` (and the sibling API tools — prs, labels, milestones, comments) a `dir=` form that resolves server + auth from that clone's remote/credential scope, mirroring what the git plane already does.

hexajon commented

2026-07-15 14:38:20 +00:00

(Migrated from codeberg.org)

Another concrete occurrence (2026-07-15), and a scope addition: madt_api_call belongs in this sweep too - it is not in the sibling list above (prs, labels, milestones, comments) but has the same launch-bound limitation.

Case: from a session launched in an unauthed scratch checkout I needed one read against Codeberg - GET /user/gpg_keys on the account that owns a correctly-authed local clone of this repo. madt_api_call has no dir= (its input struct is method/endpoint/body/raw/jq/template/paginate only; internal/mcp/tools_api.go:20) and resolves credentials via config.GetCredentials(ctx) against the server's launch environment, so the MCP call failed with not configured - run 'madtea auth login' first. The only working path was the discouraged one: running madtea api /user/gpg_keys from inside the authed clone via the shell.

One wrinkle that distinguishes it from the typed tools: owner_repo= can never substitute here. The passthrough hits endpoints like /user/gpg_keys that have no repo scope at all - dir= on madt_api_call would be purely a credential/forge-resolution selector ("call forge X as the identity configured in clone Y"), not a repo scoper. That makes it a clean data point for the #62 matrix: a remote-API tool whose correct scope is dir=, not RepoScope.

Another concrete occurrence (2026-07-15), and a scope addition: **`madt_api_call` belongs in this sweep too** - it is not in the sibling list above (prs, labels, milestones, comments) but has the same launch-bound limitation. Case: from a session launched in an unauthed scratch checkout I needed one read against Codeberg - `GET /user/gpg_keys` on the account that owns a correctly-authed local clone of this repo. `madt_api_call` has no `dir=` (its input struct is method/endpoint/body/raw/jq/template/paginate only; internal/mcp/tools_api.go:20) and resolves credentials via `config.GetCredentials(ctx)` against the server's launch environment, so the MCP call failed with `not configured - run 'madtea auth login' first`. The only working path was the discouraged one: running `madtea api /user/gpg_keys` from inside the authed clone via the shell. One wrinkle that distinguishes it from the typed tools: `owner_repo=` can never substitute here. The passthrough hits endpoints like `/user/gpg_keys` that have **no repo scope at all** - `dir=` on `madt_api_call` would be purely a credential/forge-resolution selector ("call forge X as the identity configured in clone Y"), not a repo scoper. That makes it a clean data point for the #62 matrix: a remote-API tool whose correct scope is `dir=`, not `RepoScope`.

hexajon commented

2026-07-15 14:47:03 +00:00

(Migrated from codeberg.org)

The decision I recorded in #90 (2026-07-15) appears to supersede this ask: agents must be prevented from crossing outside the launch pwd and using auth tokens found in other checkouts - the launch scope is the credential boundary. That reads as the opposite of "if a repo is cloned locally and correctly authed inside that repo's scope, any agent/user on the system should be able to file a bug against it": under that decision the sanctioned remedy for the 2026-07-14 scenario is authenticating the session's own scope (#89 in-MCP OAuth login, #88 connect-time warning), not per-repo credential targeting. #87 (the passthrough sibling of this ask) was closed under the same decision. Leaving this open until I reconcile it - see the needs-decision section of #90.

hexajon commented

2026-07-16 14:04:48 +00:00

(Migrated from codeberg.org)

Should be resolve by #90.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#59

No description provided.

Rows
Columns