dir= API-write ops resolve slug from origin but forge base URL from a stale/global madtea.url (cross-forge mismatch) #391

New issue

Closed

opened 2026-08-17 05:08:36 +00:00 by hexajon · 0 comments

hexajon commented

2026-08-17 05:08:36 +00:00

Owner

Summary

For API-write operations, a dir= target resolves the repo SLUG from the dir's origin remote but resolves the forge BASE URL from a different source (a stale or global madtea.url), producing an impossible cross-forge query: <owner>/<repo> from forge A sent to forge B. Read paths (madt_status, madt_auth_whoami) and madt_api_call resolve the same checkout correctly, so the defect is specific to the API-write resolution path.

Environment

Global git config carries madtea.url = https://gitea.inwonderland.space (forge A).
Working clone: origin remote https://git.cheshirecube.cloud/cheshirecube-cloud/platform-radar (forge B).
madtea MCP tool surface.

Steps to reproduce

madt_clone a forge-B repo. Observed: after the clone, a madtea.url pointing at forge A (the global default) is in effect for the new clone, though origin is forge B.
git config --unset madtea.url on the clone. Resolution falls through to the global madtea.url = forge A.
git config madtea.url https://git.cheshirecube.cloud on the clone (repo-level = forge B). git config --get madtea.url confirms forge B at the repo level.
madt_issues action=create dir=<clone> ....

Expected

The issue is created on forge B (git.cheshirecube.cloud), matching the clone's origin and its repo-level madtea.url.

Actual

API error 404: repo cheshirecube-cloud/platform-radar not found on gitea.inwonderland.space (POST /repos/cheshirecube-cloud/platform-radar/issues)
  forge URL:  https://gitea.inwonderland.space  (from repo config madtea.url)
  repo slug:  cheshirecube-cloud/platform-radar  (from origin remote)

The error labels the forge as coming "from repo config madtea.url", but the repo-level madtea.url was set to git.cheshirecube.cloud in step 3 and confirmed by git config --get. So the resolver does NOT read the dir's own repo-level madtea.url; it reads a global/other value, while it DOES take the slug from the dir's origin. Slug (forge B) and base URL (forge A) come from different sources, so the request can never succeed. The "(from repo config madtea.url)" label in the error is itself inaccurate.

Contrast: same checkout, correct resolution

madt_auth_whoami dir=<clone> -> active forge URL https://git.cheshirecube.cloud (origin remote). Correct.
madt_status dir=<clone> -> reports cheshirecube-cloud/platform-radar on the right forge. Correct.
madt_api_call GET /repos/cheshirecube-cloud/platform-radar -> 200. Correct forge.

Two defects

Primary: dir= API-write forge resolution ignores the dir's own repo-level madtea.url (and origin) and uses a global madtea.url; combined with the slug taken from the dir's origin, this yields a cross-forge mismatch. The error's source label is also wrong.
Related (observed, not fully isolated): after madt_clone of a forge-B repo, a madtea.url for forge A (the global default) is in effect for the new clone. A fresh clone should not carry a forge-A override for a forge-B origin.

Suggested fix

For any dir= operation, resolve the forge base URL from the SAME source as the slug: the dir's repo-level madtea.url, else its origin remote. Never a global madtea.url. Fix the error's source label to name the true source. And ensure madt_clone does not write or leave a mismatched madtea.url for the new clone's origin.

Impact and workarounds

All madtea API-write ops (issue create/comment, finish, prs) against a repo on a non-default forge fail when a global madtea.url points elsewhere. Workarounds found: use madt_api_call (resolves correctly), or clear the global madtea.url.

## Summary For API-write operations, a `dir=` target resolves the repo SLUG from the dir's origin remote but resolves the forge BASE URL from a different source (a stale or global `madtea.url`), producing an impossible cross-forge query: `<owner>/<repo>` from forge A sent to forge B. Read paths (`madt_status`, `madt_auth_whoami`) and `madt_api_call` resolve the same checkout correctly, so the defect is specific to the API-write resolution path. ## Environment - Global git config carries `madtea.url = https://gitea.inwonderland.space` (forge A). - Working clone: origin remote `https://git.cheshirecube.cloud/cheshirecube-cloud/platform-radar` (forge B). - madtea MCP tool surface. ## Steps to reproduce 1. `madt_clone` a forge-B repo. Observed: after the clone, a `madtea.url` pointing at forge A (the global default) is in effect for the new clone, though origin is forge B. 2. `git config --unset madtea.url` on the clone. Resolution falls through to the global `madtea.url` = forge A. 3. `git config madtea.url https://git.cheshirecube.cloud` on the clone (repo-level = forge B). `git config --get madtea.url` confirms forge B at the repo level. 4. `madt_issues action=create dir=<clone> ...`. ## Expected The issue is created on forge B (git.cheshirecube.cloud), matching the clone's origin and its repo-level `madtea.url`. ## Actual ``` API error 404: repo cheshirecube-cloud/platform-radar not found on gitea.inwonderland.space (POST /repos/cheshirecube-cloud/platform-radar/issues) forge URL: https://gitea.inwonderland.space (from repo config madtea.url) repo slug: cheshirecube-cloud/platform-radar (from origin remote) ``` The error labels the forge as coming "from repo config madtea.url", but the repo-level `madtea.url` was set to git.cheshirecube.cloud in step 3 and confirmed by `git config --get`. So the resolver does NOT read the dir's own repo-level `madtea.url`; it reads a global/other value, while it DOES take the slug from the dir's origin. Slug (forge B) and base URL (forge A) come from different sources, so the request can never succeed. The "(from repo config madtea.url)" label in the error is itself inaccurate. ## Contrast: same checkout, correct resolution - `madt_auth_whoami dir=<clone>` -> active forge URL `https://git.cheshirecube.cloud` (origin remote). Correct. - `madt_status dir=<clone>` -> reports `cheshirecube-cloud/platform-radar` on the right forge. Correct. - `madt_api_call GET /repos/cheshirecube-cloud/platform-radar` -> 200. Correct forge. ## Two defects 1. Primary: `dir=` API-write forge resolution ignores the dir's own repo-level `madtea.url` (and origin) and uses a global `madtea.url`; combined with the slug taken from the dir's origin, this yields a cross-forge mismatch. The error's source label is also wrong. 2. Related (observed, not fully isolated): after `madt_clone` of a forge-B repo, a `madtea.url` for forge A (the global default) is in effect for the new clone. A fresh clone should not carry a forge-A override for a forge-B origin. ## Suggested fix For any `dir=` operation, resolve the forge base URL from the SAME source as the slug: the dir's repo-level `madtea.url`, else its origin remote. Never a global `madtea.url`. Fix the error's source label to name the true source. And ensure `madt_clone` does not write or leave a mismatched `madtea.url` for the new clone's origin. ## Impact and workarounds All madtea API-write ops (issue create/comment, finish, prs) against a repo on a non-default forge fail when a global `madtea.url` points elsewhere. Workarounds found: use `madt_api_call` (resolves correctly), or clear the global `madtea.url`.

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:51:42 +00:00

Commit signing does not travel with the forge credential: signed-commit forges are unworkable via madtea #424

hexajon referenced this issue