Repository navigation
[Feature]: Add Forgejo as Source Control Provider #2536
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I am describing a concrete problem or use case, not just a vague idea.
Area
Not sure
Problem or use case
Besides GH, GL and BB, it would be great to also have support for Forgejo. There is fj as the CLI which can be used for the underlying API calls.
Proposed solution
Add support for Forgejo Git platforms.
Ideally multiple instances would be supported from the beginning as many people operate on more than just one instance. Also there is no single default instance anyhow so T3CODE_FORGEJO_URL or similar would anyhow be required.
Why this matters
Forgejo is a modern alternative to existing Forges like GH and GL.
Smallest useful scope
Allowing to link at least one Forgejo instance.
Alternatives considered
No response
Risks or tradeoffs
No response
Examples or references
No response
Contribution
- I would be open to helping implement this.
Reacted by Demir Yerli, Romain Gallez, James Stone, Soop24, Brian Mitchell, nbross, Mario Gabriell Karaziaki, Héphaïstos, Mathieu R., Noah Füreder and 10 more
Activity
hazrpg commentedon Jul 5, 2026
This would also help Gitea users too - since the API is backward compatible with it. And I'd love to see both forgejo and gitea compatibility.
pkeech commentedon Jul 11, 2026
+1 for getting this added!
RobbyV2 commentedon Jul 26, 2026
+1! A lot of organizations use either forgejo and gitea (and forks), it would be super helpful :)
gustavohariel commentedon Jul 28, 2026
+1 on this!
hack13 commentedon Jul 30, 2026
+1 on this as well, as a selfhoster I would love native integration
petmar20 commentedon Aug 11, 2026
+1 Hoping for gitea support. Seems like this issue has been open a long time.
insalata-fresca commentedon Aug 12, 2026
I wanted this for my self-hosted Forgejo, so I built it — a complete implementation is ready on a branch in case it's useful here:
https://github.com/insalata-fresca/t3code/tree/forgejo-provider (single commit on current
main; 22 files, +2,033/−10 — roughly 40% of that is tests)Design notes, following the existing Bitbucket (API-token) provider idiom as closely as possible:
SourceControlProvider: list/get/create pull requests, PR checkout (incl. fork remotes), create repository, clone URLs, default branch — against the Forgejo v1 APIT3CODE_FORGEJO_API_BASE_URL+T3CODE_FORGEJO_API_TOKEN(Gitea-styleAuthorization: tokenscheme). The base-URL env addresses the self-hosted/no-default-instance point from the issue descriptionforgejo/gitea/codebergsubstrings — so Gitea instances and Codeberg work too, per the comments abovefj, but the API route matched the existing Bitbucket provider shape better)sourceControl,pullRequest, shared and client-runtime suites green; monorepo typecheck clean; zero new dependenciesKnown gap: the new multi-provider PR page would additionally need a
ForgejoPullRequestProviderto light up for Forgejo remotes — happy to add that as a follow-up.I read CONTRIBUTING and know large feature PRs aren't wanted right now, so I'm deliberately not opening one unprompted. If this is something you'd take, say the word and I'll open the PR (and split or trim it however you prefer) — otherwise feel free to lift anything useful from the branch.
Built with AI assistance (Claude), reviewed and deployed by me.
quasarea commentedon Aug 12, 2026
I researched the current implementations and would like to propose a coordination path before adding another one.
There is now a released shared
forgejo-bridgev0.2.0 (release commit9000369ee452336d99309889415190f665918246) used by Codex through a packaged MCP integration. Its contract intentionally centralizes multi-instance selection, credentials, repository policy, pagination, Forgejo 15/16 compatibility, normalized errors, and capability discovery. T3 would invoke the same bridge through its JSON CLI boundary; it would not read tokens or implement Forgejo REST behavior itself.PR #3028 already contains valuable first-class T3 work: the provider kind, registry refinement, remote UX, checkout mechanics, web/mobile presentation, and tests. Rather than create a competing implementation, I propose retaining those pieces and replacing
ForgejoApi/ForgejoKeyStorewith a thin bridge adapter.A deliberately small first PR could support:
Repository/PR creation and richer review/Actions mutations would remain capability-gated follow-ups. Generic Git URL cloning would continue to work without the bridge.
Important distribution caveat: the bridge is released and deployed in our environment, but is not yet a public dependency suitable for general T3 users. Before preparing code, would maintainers accept an optional external bridge boundary in principle, assuming a public/installable distribution is provided? If so, I am happy to coordinate with @pat-s and adapt the existing PR rather than duplicate it.
quasarea commentedon Aug 12, 2026
Follow-up: the distribution prerequisite is now resolved.
The bridge has been published as a clean, single-root-commit public repository:
db1d692d7789b6336bc645eecd5eff47dd7606e5go vet, formatting, and build passThe public history excludes private deployment wrappers, instance configuration, credentials, and consumer-specific customization. The proposed T3 boundary remains a thin optional CLI adapter over the versioned JSON contract.
pat-s commentedon Aug 12, 2026
Codeberg is not a forge but an instance (!!) that runs Forgejo - I wonder how often I will have to type this in the next years... :/ Basically stopped reading there.
You could at least have waited for more than 20min for a reply before building a completely unneeded "bridge" using an anonymous throw-away account.
All of this is what people legitimately refer to as "AI slop" - and while I hate the term itself, it really needs to be understood that this needs to stop. With this I mean these anonymous, "on the side" coding and posting automation without thinking about what is needed, where this fits in and how it will be perceived. Use AI as a tool to create quality work and not just something that can be compiled and "fixes" something in a hacky way that isn't sustainable.
Such contributions are close to spam and they don't help anyone - instead they create noise that prevents other from moving forward (I've now lost 10 min of my life in this rant).
/rant off