feat(repo-scope): target a repo on another forge host without a local clone #468

New issue

Open

opened 2026-09-04 16:33:51 +00:00 by hexajon · 0 comments

hexajon commented

2026-09-04 16:33:51 +00:00

Owner

owner_repo can retarget a repo on the forge the session is already anchored to, but it cannot name a repo on a DIFFERENT forge host. So there is no clone-free way to act on a repo that lives on another forge instance.

What happens

A session resolves its forge and token from the launch-scope working directory (madt_help repo-scope; madt_auth_login authenticates "this MCP session to the launch-scope forge").
owner_repo is host-less (the docs use owner_repo="octocat/hello"). It selects a repo on the ALREADY-resolved forge. It has no field for a host.
To act on a repo on another forge (for example, filing an issue against a project whose origin is a different forge instance), the only path is dir=<local clone>, which carries that clone's origin and its own stored credentials.

Concretely: from a session anchored to forge A, I wanted to file an issue against a repo on forge B. owner_repo=owner/repo would have aimed at forge A (wrong host, or a 404). The write only worked because I had a local clone of the forge-B repo and could pass dir=.

Why this is a gap, not a guardrail

Issue create / comment / list / get are explicitly PERMITTED through the dir= carve-out, so there is no safety reason they must route through a local checkout. The clone does one job only here: it tells madtea which forge and which token to use. A user with no local clone of the target has no way to reach it at all.

Possible directions

Two independent pieces, either of which helps:

Host-qualified targeting: let owner_repo (or a new host= / forge= selector) name the forge, e.g. owner_repo=<host>/owner/repo, so a target on another forge is expressible.
Multi-forge session auth: resolve a token per target host (a host-keyed credential store), so a named remote host authenticates without borrowing a local checkout's credential chain.

Relation to existing issues

Same root area as the host-resolution cluster (#460 open; #459, #429 closed) and forge reachability (#455), but none of those cover clone-free WRITE targeting across forges. This is the write-side capability, not the status-output correctness those track.

This touches the forge and credential-resolution model, so I should reconcile it against docs/architecture/technical-choices.md when it is scoped.

Acceptance

I can file or comment on an issue in a repo on another forge host with no local clone present, given valid credentials for that host.
A host-less owner_repo keeps its current behavior (targets the launch-scope forge).
The behavior is documented in madt_help repo-scope.

`owner_repo` can retarget a repo on the forge the session is already anchored to, but it cannot name a repo on a DIFFERENT forge host. So there is no clone-free way to act on a repo that lives on another forge instance. ### What happens - A session resolves its forge and token from the launch-scope working directory (`madt_help repo-scope`; `madt_auth_login` authenticates "this MCP session to the launch-scope forge"). - `owner_repo` is host-less (the docs use `owner_repo="octocat/hello"`). It selects a repo on the ALREADY-resolved forge. It has no field for a host. - To act on a repo on another forge (for example, filing an issue against a project whose origin is a different forge instance), the only path is `dir=<local clone>`, which carries that clone's origin and its own stored credentials. Concretely: from a session anchored to forge A, I wanted to file an issue against a repo on forge B. `owner_repo=owner/repo` would have aimed at forge A (wrong host, or a 404). The write only worked because I had a local clone of the forge-B repo and could pass `dir=`. ### Why this is a gap, not a guardrail Issue `create` / `comment` / `list` / `get` are explicitly PERMITTED through the `dir=` carve-out, so there is no safety reason they must route through a local checkout. The clone does one job only here: it tells madtea which forge and which token to use. A user with no local clone of the target has no way to reach it at all. ### Possible directions Two independent pieces, either of which helps: 1. Host-qualified targeting: let `owner_repo` (or a new `host=` / `forge=` selector) name the forge, e.g. `owner_repo=<host>/owner/repo`, so a target on another forge is expressible. 2. Multi-forge session auth: resolve a token per target host (a host-keyed credential store), so a named remote host authenticates without borrowing a local checkout's credential chain. ### Relation to existing issues Same root area as the host-resolution cluster (#460 open; #459, #429 closed) and forge reachability (#455), but none of those cover clone-free WRITE targeting across forges. This is the write-side capability, not the status-output correctness those track. This touches the forge and credential-resolution model, so I should reconcile it against `docs/architecture/technical-choices.md` when it is scoped. ### Acceptance - I can file or comment on an issue in a repo on another forge host with no local clone present, given valid credentials for that host. - A host-less `owner_repo` keeps its current behavior (targets the launch-scope forge). - The behavior is documented in `madt_help repo-scope`.

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#468

No description provided.

Rows
Columns