[Bug]: Gitea showing Not Authenticated, even when it's authenticated through tea cli

[projectashik]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

I used the gitea self hosted instance and I've configured the tea cli too. But on the t3code settings it's showing not authenticated.

Expected behavior

It should show authenticated and allow to use that in T3Code.

Actual behavior

I used the gitea self hosted instance and I've configured the tea cli too. But on the t3code settings it's showing not authenticated.

Impact

Minor bug or occasional failure

Version or commit

0.0.43-nightly.20260917.1866

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Thanks for the screenshots — this is a real false negative, not a broken Gitea login.

What we see

• Settings shows Forgejo / Gitea with tea 0.14.2 and the Not authenticated badge.
• tea whoami on the same machine returns ashik (admin), so the token works.

Why Settings lies
T3 Code’s Forgejo/Gitea discovery treats tea as present after tea --version, then checks auth with:

tea login status --output json

That command landed in tea 0.16.0 (2026-09-10). On 0.14.2 it does not exist. The probe fails, JSON parse returns no logins, and Settings maps that to Not authenticated plus “sign in with tea”.

A successful parse still requires valid === "true". tea login list does not emit valid, so falling back to list without a code change would still show unauthenticated.

Docs already say tea 0.16 or later (docs/user/source-control.md). The UI never surfaces that when the probe fails.

Relevant code:

• apps/server/src/sourceControl/ForgejoSourceControlProvider.ts (authArgs, parseAuth)
• apps/web/src/components/settings/SourceControlSettings.tsx (badge / copy)
• Shipped in feat(source-control): support Forgejo and Gitea with fj and tea #11436

Workaround
On the machine running the T3 Code server (same host Settings scanned):

1. Install tea 0.16.0+.
2. Confirm tea --version is 0.16 or later, and tea login status --output json lists your login with "valid": "true".
3. Settings → Source Control → Rescan.

If login status reports valid: false after the upgrade, the stored token cannot reach /api/v1/user (URL, TLS/--insecure, or scopes). whoami working on 0.14.2 makes that less likely once 0.16 is on PATH.

Product follow-up
Keep this open:

1. If tea is < 0.16, show “update tea to 0.16+” instead of Not authenticated.
2. Optionally fall back to tea login list / tea whoami when login status is missing.

Please comment with the new tea --version and whether Rescan flips to Authenticated after upgrading.

[projectashik]

I upgraded the CLI and re-logged in and it worked after that.

[projectashik]

New cli version: 0.16.0
And worked on it.

Thank you.