fix: status --json reports the auth-target host, not the repo's own remote host #429

New issue

Closed

opened 2026-08-17 16:51:13 +00:00 by hexajon · 0 comments

hexajon commented

2026-08-17 16:51:13 +00:00

Owner

Summary

madtea status --json sets .host to the host of the configured/authenticated server, not the host of the current repo's own remote. When the working repo's origin points at a different Forgejo/Gitea instance than the one madtea is authenticated against, .host is wrong.

Repro

Authenticate madtea against forge A (host forge-a.example).
cd into a clone whose origin points at forge B (host forge-b.example).
Run madtea status --json.

Observed:

.host = forge-a.example (the auth target).
.owner and .repo are correct for forge B (parsed from the local remote).

Expected:

.host = forge-b.example (the repo's actual remote host).

The data is available; only `status` uses the wrong source

Two other surfaces resolve the correct remote host for the same repo:

madtea repo view --json returns clone_url and html_url on forge-b.example.
The MCP madt_status tool (dir-targeted) returns "host": "forge-b.example" and "foreignPrimary": true.

So the local remote is parsed correctly elsewhere. Only status --json .host reports the auth target.

Why it matters

.host is the natural token-free field for "which forge does this repo live on". A caller that trusts it to gate per-forge behavior gets the auth target for every repo, so every repo looks like it lives on the configured server. repo view needs a network round trip; a correct local .host would avoid that.

Suggested fix

Make status .host report the host parsed from the repo's own remote, the same value madt_status and repo view already return. If the auth-target host is also useful, expose it under a separate field.

Version

madtea version v0.18.4

## Summary `madtea status --json` sets `.host` to the host of the configured/authenticated server, not the host of the current repo's own remote. When the working repo's `origin` points at a different Forgejo/Gitea instance than the one madtea is authenticated against, `.host` is wrong. ## Repro 1. Authenticate madtea against forge A (host `forge-a.example`). 2. `cd` into a clone whose `origin` points at forge B (host `forge-b.example`). 3. Run `madtea status --json`. Observed: - `.host` = `forge-a.example` (the auth target). - `.owner` and `.repo` are correct for forge B (parsed from the local remote). Expected: - `.host` = `forge-b.example` (the repo's actual remote host). ## The data is available; only `status` uses the wrong source Two other surfaces resolve the correct remote host for the same repo: - `madtea repo view --json` returns `clone_url` and `html_url` on `forge-b.example`. - The MCP `madt_status` tool (dir-targeted) returns `"host": "forge-b.example"` and `"foreignPrimary": true`. So the local remote is parsed correctly elsewhere. Only `status --json .host` reports the auth target. ## Why it matters `.host` is the natural token-free field for "which forge does this repo live on". A caller that trusts it to gate per-forge behavior gets the auth target for every repo, so every repo looks like it lives on the configured server. `repo view` needs a network round trip; a correct local `.host` would avoid that. ## Suggested fix Make `status .host` report the host parsed from the repo's own remote, the same value `madt_status` and `repo view` already return. If the auth-target host is also useful, expose it under a separate field. ## Version `madtea version v0.18.4`

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

2026-08-27 04:40:19 +00:00

fix(status): report the repo's own origin host in status --json, not the auth target #459

hexajon referenced this issue from a commit

2026-08-27 04:40:20 +00:00

fix(status): report the repo's own origin host in status --json, not the auth target (#429)

hexajon closed this issue

2026-08-27 04:40:21 +00:00

hexajon referenced this issue

2026-08-27 04:40:58 +00:00

status --json .host uses the cwd origin while .owner/.repo follow the --repo override #460

hexajon referenced this issue