Repository navigation
[Bug]: T3 Connect CLI GitHub sign-in returns 500 FUNCTION_INVOCATION_FAILED #11904
Description
Activity
Triage
This looks like a real upstream Clerk failure on the hosted Account Portal, not a T3 Code
/connector CLI callback bug.npx t3 connecton a local machine prints ahttps://app.t3.codes/connect#…URL. After GitHub sign-in, the hosted page sends the browser to Clerk’s/oauth/authorize(PKCE, loopbackhttp://127.0.0.1:34338/callback). Clerk then renders Account Portal sign-in and/auth-consent. That consent page is what returned:500 FUNCTION_INVOCATION_FAILED yul1::pfh97-1789483902569-f81f3c242689FUNCTION_INVOCATION_FAILED+ theyul1::id is a Cloudflare Worker crash.accounts.t3.codes//auth-consentis Clerk’s Account Portal, not a route in this repo. The CLI waiting on the authorization code is expected once that page dies.This is not a duplicate of:
- [Bug]: Desktop: T3 Connect OAuth sign-in dead-ends on "Not Found" — Clerk virtual-router URL leaks into the hash-routed renderer after the deep-link callback #7512 — desktop Clerk virtual-router “Not Found” after the
t3code://callback - [Bug]: T3 Connect desktop OAuth callback fails — Clerk rejects response_type / 'Invalid T3 Connect authorization callback' (Windows, v0.0.30-v0.0.32-nightly) #5051 — loopback landed on
127.0.0.1withInvalid T3 Connect authorization callback(addressed by fix(connect): preserve CLI OAuth parameters through browser sign-in #6285 / fix(web): unstick /connect after in-modal sign-in by redirecting to the authorize endpoint #5133)
npx t3@latestis still 0.0.40 (2026-09-08), so this report is the loopback/connect→/oauth/authorizepath, not the device-grant client from #11794 (merged 2026-09-14). Enabling Clerk’s beta Device authorization grant on the CLI OAuth app for that PR is still worth checking — it can affect the same hosted consent page.Next step
@juliusmarminge (or anyone with Clerk dashboard access): look up invocation
yul1::pfh97-1789483902569-f81f3c242689, inspect Account Portal/auth-consentlogs, and confirm GitHub → consent still works for the CLI OAuth app. Compare Google/email. No T3 application-code change until that result is known.Workarounds to try
- Sign in with Google or email instead of GitHub
- Desktop-managed SSH or Tailscale pairing (bypasses this Clerk consent step)
@nosliwsirhc if you can add
npx t3 --version(or the versionnpx t3@latestprinted) and whether a retry or a non-GitHub method gets past/auth-consent, that will help confirm whether this is still failing.- [Bug]: Desktop: T3 Connect OAuth sign-in dead-ends on "Not Found" — Clerk virtual-router URL leaks into the hash-routed renderer after the deep-link callback #7512 — desktop Clerk virtual-router “Not Found” after the
"t3 v0.0.40" is the version on the workstation. Interestingly, when I tried to use another provider by starting the process again, the browser picked up the previous Github login credentials and allowed me to complete the process - so I'm in. However, here is a screenshot of the error I originally encountered.
Before submitting
Area
Not sure
Steps to reproduce
On a Fedora Linux machine, run:
The CLI prints a browser URL and waits for an authorization code to be pasted back into the terminal.
Open the generated URL in Google Chrome.
Choose GitHub as the sign-in method and sign in with a GitHub account.
The browser reaches an
accounts.t3.codes/sign-inURL whose redirect points to the/auth-consentflow.Instead of showing the consent/code page, the hosted page displays a server error.
The complete authorization URL is intentionally omitted because it may contain temporary authentication parameters.
Observed on September 15, 2026, at approximately 10:52 AM Eastern.
Expected behavior
After GitHub authentication, the browser should show the T3 Connect authorization/consent result and provide the code needed by the waiting
t3 connectprocess. The Fedora environment should then be linked to the T3 account.Actual behavior
The browser displays:
The authorization flow cannot complete and the CLI remains unable to link the Fedora environment.
This appears to fail on the hosted
accounts.t3.codespage before the authorization code is returned, rather than during the desktop application's post-OAuth callback handling.Impact
Major degradation or frequent failure
T3 Connect cannot be configured through the documented CLI flow. Other remote-access methods may still be available.
Version or commit
Latest version resolved by
npx t3@latest connecton September 15, 2026. The exact resolved version was not captured.Environment
npx t3@latest connectaccounts.t3.codesLogs or stack traces
No terminal error was produced before the browser failure; the CLI was waiting for the authorization code.
Screenshots, recordings, or supporting files
A screenshot was captured showing the hosted error page and the invocation ID. The authorization URL was redacted.
Workaround
Desktop-managed SSH or direct Tailscale pairing may bypass T3 Connect account authentication, but neither workaround has been verified as part of this reproduction.
Related issue
#7512 concerned an OAuth flow that reached the desktop callback and then displayed a
Not Foundroute. This report appears different because the hostedaccounts.t3.codespage itself returns HTTP 500 before the consent/code step completes.