Fjord-Account hosts: git clone/push not routed through the gateway (API-only parity gap) #222

New issue

Open

opened 2026-07-21 16:13:42 +00:00 by stephen · 0 comments

stephen commented

2026-07-21 16:13:42 +00:00

Owner

Summary

For a Fjord-Account host, fj drives the forge at the API level through the gateway, but git operations (clone/push/fetch) do not flow through the gateway. This is the one remaining parity gap between a Fjord-Account host and a PAT host.

Evidence (HEAD `1251c71`)

fj auth setup-git explicitly refuses for Fjord hosts (src/cli/auth_setup_git.rs:18):

"fj auth setup-git is for Forgejo PAT hosts. Fjord Account git credential helpers are not yet implemented (git pushes don't currently flow through the gateway)."
web_base_url for a FjordAccount host (src/client/resolve.rs:100) resolves git URLs against the instance's cached default_instance_public_url (the raw forge origin), and there is no fj credential helper installed for that host. So git clone / git push / git fetch target the forge directly with no fj-provided credential.
For a linked external instance this is especially stuck: the PAT that would authorize git is held server-side by the platform and never reaches the device.

By contrast, all REST/API ops route correctly through gateway_base_url(platform, default_instance_id) with Authorization: Bearer <jwt> (src/client/mod.rs:66-82; integration test fjord_client_routes_through_gateway_with_bearer).

Impact

Any fj workflow that shells out to git against a Fjord-selected instance (pr checkout, repo clone, develop, stack push) has no working credential. API-only flows are unaffected.

Possible directions (not a decision)

Route git-over-HTTPS for Fjord hosts through the gateway (a git-gateway-style path), or
Mint a short-lived, instance-scoped credential and install a Fjord-aware git credential helper (lift the setup-git refusal).

Origin

Surfaced by the Fjord-account login spike (managed + external forge control via fj instances + the gateway). API-level control is complete and code-proven; this git seam is the delta to full parity.

## Summary For a Fjord-Account host, fj drives the forge at the **API level** through the gateway, but **git operations (clone/push/fetch) do not flow through the gateway**. This is the one remaining parity gap between a Fjord-Account host and a PAT host. ## Evidence (HEAD `1251c71`) - `fj auth setup-git` explicitly refuses for Fjord hosts (`src/cli/auth_setup_git.rs:18`): > "`fj auth setup-git` is for Forgejo PAT hosts. Fjord Account git credential helpers are not yet implemented (git pushes don't currently flow through the gateway)." - `web_base_url` for a `FjordAccount` host (`src/client/resolve.rs:100`) resolves git URLs against the instance's cached `default_instance_public_url` (the raw forge origin), and there is no fj credential helper installed for that host. So `git clone` / `git push` / `git fetch` target the forge directly with no fj-provided credential. - For a **linked external** instance this is especially stuck: the PAT that would authorize git is held server-side by the platform and never reaches the device. By contrast, all REST/API ops route correctly through `gateway_base_url(platform, default_instance_id)` with `Authorization: Bearer <jwt>` (`src/client/mod.rs:66-82`; integration test `fjord_client_routes_through_gateway_with_bearer`). ## Impact Any fj workflow that shells out to git against a Fjord-selected instance (`pr checkout`, `repo clone`, `develop`, stack push) has no working credential. API-only flows are unaffected. ## Possible directions (not a decision) - Route git-over-HTTPS for Fjord hosts through the gateway (a `git-gateway`-style path), or - Mint a short-lived, instance-scoped credential and install a Fjord-aware git credential helper (lift the `setup-git` refusal). ## Origin Surfaced by the Fjord-account login spike (managed + external forge control via `fj instances` + the gateway). API-level control is complete and code-proven; this git seam is the delta to full parity.

stephen added the

backlog

labels

2026-07-21 16:13:42 +00:00