ux(clone): shorthand clone resolves the forge silently from ambient state — mirror-trap; say which host, warn on mirror=true #97

New issue

Closed

opened 2026-07-15 15:21:16 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-15 15:21:16 +00:00

(Migrated from codeberg.org)

How I got a wrong-forge clone without noticing (2026-07-15): madtea clone sixfold_space/madtea resolves the FORGE for a shorthand from ambient config (session/global/host-keyed creds), not from any property of the repo the user has in mind. On a machine where a Gitea instance MIRRORS the codeberg repo under the same owner/repo, the identical command clones from whichever forge is ambiently resolvable that day: before a codeberg auth login it cloned the read-only Gitea mirror (stamping a gitea host and user); after the login the same command clones codeberg (stamping codeberg, hexajon). Byte-identical content, so nothing looks wrong — until a later auth login with a codeberg token 404s against the stamped gitea URL, or a push bounces off the read-only mirror.

Asks:

clone output must NAME the forge host it resolved: Cloned into '...' (branch: main) says nothing; Cloned sixfold_space/madtea from <forge-host> into '...' would have surfaced the trap on day one. Same line should appear in the MCP madt_clone result.
The clone response includes mirror: true in the repo metadata — when set, warn loudly: this is a read-only mirror, pushes will fail, and name the config knob if the user meant the source repo (a mirror's API metadata may carry the original URL).
Consider the same forge-host echo on auth whoami-adjacent stamping ops (auth login already prints the URL — clone is the outlier).

Not asking for interactive disambiguation of shorthands — just loud, honest output about which forge was chosen and whether the result is a mirror.

How I got a wrong-forge clone without noticing (2026-07-15): `madtea clone sixfold_space/madtea` resolves the FORGE for a shorthand from ambient config (session/global/host-keyed creds), not from any property of the repo the user has in mind. On a machine where a Gitea instance MIRRORS the codeberg repo under the same owner/repo, the identical command clones from whichever forge is ambiently resolvable that day: before a codeberg `auth login` it cloned the read-only Gitea mirror (stamping a gitea host and user); after the login the same command clones codeberg (stamping codeberg, hexajon). Byte-identical content, so nothing looks wrong — until a later `auth login` with a codeberg token 404s against the stamped gitea URL, or a push bounces off the read-only mirror. Asks: 1. `clone` output must NAME the forge host it resolved: `Cloned into '...' (branch: main)` says nothing; `Cloned sixfold_space/madtea from <forge-host> into '...'` would have surfaced the trap on day one. Same line should appear in the MCP madt_clone result. 2. The clone response includes `mirror: true` in the repo metadata — when set, warn loudly: this is a read-only mirror, pushes will fail, and name the config knob if the user meant the source repo (a mirror's API metadata may carry the original URL). 3. Consider the same forge-host echo on `auth whoami`-adjacent stamping ops (`auth login` already prints the URL — clone is the outlier). Not asking for interactive disambiguation of shorthands — just loud, honest output about which forge was chosen and whether the result is a mirror.

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

No description provided.

Rows
Columns