[Feature]: Support gt, the new official Gitea CLI that replaces the archived tea

[hakubo]

Summary

tea has been archived. Its README now says:

tea has been replaced by gt, the new official CLI for Gitea, and this repository will be archived. Please use gt and open new issues and pull requests at https://gitea.com/gitea/cli.

T3 Code's Forgejo/Gitea integration only knows about fj and tea. New Gitea users will install gt, and T3 Code won't detect it. They'll see "Not authenticated" / "Install Forgejo CLI (fj 0.6 or later) or Gitea CLI (tea 0.16 or later)" and won't know why.

Where tea is hard-coded

• packages/source-control-forgejo/src/server/ForgejoCli.ts
  • command: Schema.Literals(["fj", "tea"])
  • Login discovery runs tea login list --output json
  • API calls run tea api --include --login <login> --repo <repo> --method … <url>, and the HTTP status is parsed from stderr because tea exits 0 on HTTP errors
  • Error and help strings mention tea login add and tea login default
• packages/source-control-forgejo/src/shared/definition.ts: CHECKOUT_COMMAND and changeRequestCloseCommand regexes match tea pr|pulls …; searchKeywords includes "tea"
• docs/user/source-control.md: links to https://gitea.com/gitea/tea and documents tea login add / tea login default

What changes with gt

From Migrating from tea and the gt README:

tea	gt
tea login add	gt auth login (--with-token or --oauth)
tea login list, tea whoami	gt auth status
tea login default	gt auth switch
--login, -l	--host and --user
--repo, -r	--repo, -R
--output json	--json, --jq
tea pulls …	gt pr …

Other differences:

• gt has its own config (config.yml, hosts.yml) and doesn't read tea's, so users have to log in again
• Credentials go in the OS keyring by default; --credential-store file is opt-in
• GITEA_TOKEN plus GITEA_CLI_HOST / GITEA_INSTANCE_URL are supported for headless setups. This is relevant to T3 Code servers running as a background service.
• gt requires Gitea 28 or newer, so tea may still be needed for older instances

Proposal

1. Detect gt alongside fj and tea. Suggested order: fj → gt → tea, keeping tea as a legacy fallback for Gitea < 28 and existing setups.
2. Read logins from gt auth status --json, or whatever gt exposes for this, and make API requests through gt api (or the equivalent) using --host/--user instead of --login.
3. Check whether gt api reports HTTP failures through its exit code, so the stderr status parsing workaround only applies to tea.
4. Recognize gt pr checkout|merge|close in CHECKOUT_COMMAND / changeRequestCloseCommand, and add "gt" to searchKeywords.
5. Update the docs, error messages and Settings to point to https://gitea.com/gitea/cli and gt auth login.

Related

• [Bug]: Gitea showing Not Authenticated, even when it's authenticated through tea cli #12297: Gitea showing Not Authenticated even when authenticated through tea CLI
• [Bug]: Gitea repositories incorrectly identified as Forgejo in PR context menu #21526: Gitea repositories identified as Forgejo

[hakubo]

Maybe instead of supporting all versions t3 code supports only the lastest ones but in exchange it offers updating gh, gt, and other clis as part of updating all machines alongside t3 and providers?

[juliusmarminge]

Closing as a duplicate of #27210, which tracks the same request. Please follow along there.

[mcepl]

??? #27210 has been closed as a duplicate of this discussion. ???

[jensneuber]

@juliusmarminge this should not be closed

[kyledevans]

This discussion was closed as a duplicate of #27210, but #27210 is the issue that was converted into this discussion, and it's now locked. So nothing is currently tracking gt support. Could this be reopened?

Adding a real-world case. tea is archived upstream, and its README tells users to switch to gt, which is what we did:

• T3 Code desktop 0.1.6 (Windows)
• Self-hosted Gitea 28.3.0
• gt 1.0.0; tea uninstalled

Since the switch, T3 Code no longer shows any of our Gitea PRs. The server log shows it still only tries fj/tea:

ProcessSpawnError: NotFound: ChildProcess.spawn (tea login list --output json)
  Error: spawn tea ENOENT
...
WARN pull request sync skipped
  reason: "Change requests cannot be browsed for this project's host yet."

ForgejoCli.ts on main still has command: Schema.Literals(["fj", "tea"]). A tea → gt shim isn't a workaround: gt's commands are different (gt auth status --json instead of tea login list --output json, --host instead of --login, and so on), so the only option right now is to keep the archived tea installed.

The UI also doesn't say anything is wrong. The pull requests page just shows no PRs, which is the problem in #29453.

[Mahoke]

Could this discussion be reopened, or linked to an active tracker? It was closed as a duplicate of #27210, but #27210 was converted into this very discussion and locked, so the duplicate links form a closed circle with no active tracker.

[Spongman]

@juliusmarminge please reopen this, this is a locked loop:

Closing as a duplicate of #27210

[Wanghaoyihaoyi]

@juliusmarminge This discussion was closed as a duplicate of #27210, but #27210 is the issue that was converted into this discussion and is now locked, so nothing tracks gt support at the moment. Could it be reopened?

I have a working implementation and would like to confirm direction and scope before opening a PR, per CONTRIBUTING.

Branch: https://github.com/Wanghaoyihaoyi/t3code/tree/feat/forgejo-gt-cli (one commit on top of main, packages/source-control-forgejo and docs/user/source-control.md only)

What it does

• Reads accounts from gt auth status --json and sends API requests through gt api --include --host <instance>. Pull requests, reviews, merges, checks and the PR watcher already go through ForgejoCli.api, so they work unchanged.
• Login order is fj → gt → tea, as proposed in the original issue. fj setups spawn nothing new; tea setups see one extra gt probe before tea login list.
• Maps gt's exit codes to the existing error reasons: 4 (credential missing or rejected) → authentication; 1 with the HTTP status from --include → forbidden / not-found / rate-limit.
• Instances mounted below a URL path and several instances side by side are selected with --host. A bare owner/repo uses gt's default_host.
• T3 Code never reads gt's token, and error text never includes CLI stderr.
• A different tool that installs a gt binary (Graphite, for example) is treated as "no gt login", not an error.

How I checked it

• gt 0.2.0 against a self-hosted Gitea 28.3.0: repository resolution, PR list, 404 mapping and default-branch read, all read-only.
• vp run check:changed passes: format, lint, knip, typecheck of 11 affected packages, 74 tests in 5 files.
• New ForgejoCli.test.ts covers CLI selection order, all three CLIs missing, multiple hosts, a mounted instance, rejected or expired credentials, HTTP failures, a truncated JSON response, and secrets staying out of error text.

Known limits

• gt auth status --json does not report an SSH host, so an SSH remote matches a gt login by hostname only.
• Checkout uses git fetch refs/pull/N/head, the same path as fj, rather than gt pr checkout.

Two questions before I open a PR:

1. Is fj → gt → tea the order you want, or should gt come first?
2. Is one PR for discovery, auth and the API transport acceptable, or would you prefer it split?

Implemented with Claude Code (Claude Fable 5.2).

[Wanghaoyihaoyi]

Follow-up with a real-client check.

Running the branch as the desktop app (vp run dev:desktop) on macOS with gt 0.2.0 signed in to a self-hosted Gitea 28.3.0, and neither fj nor tea installed:

• Settings → Source control shows Forgejo / Gitea as available with the gt version and account.
• After adding a project whose remote is on that Gitea server, its pull requests load in the Pull requests list, grouped under Authored and Others as on GitHub.

The repository is private, so I have not attached a screenshot here. I can provide one from a public test repository with the PR if that helps.

One defect surfaced during this pass and is fixed on the branch: the Settings probe reported Forgejo / Gitea as not installed when the open project's remote was on another host (a GitHub project, in my case). It now falls back to gt's default login the way the fj probe does, with a test for that case.

[kyledevans]

It looks like this issue has fallen through the cracks. Has anyone reached out to a maintainer on discord? I can, but just looking at how active this project is for a 3-person team makes me extra cautious that I don't just add to the chaos.

[Spongman]

Just submit a Pr

[Wanghaoyihaoyi]

Thanks! I already have gt support implemented in my fork, including tests and docs: https://github.com/Wanghaoyihaoyi/t3code/tree/feat/forgejo-gt-cli

I shared the implementation and scope above. I’m just waiting for a maintainer to give the go-ahead before opening the PR. Could a maintainer confirm whether this change would be welcome?

[juliusmarminge]

Sorry.. automation gone bad.

Do they not just have an API we can use? I hate relying on clis

[Spongman]

https://docs.gitea.com/api/