[Bug]: "Failed to fetch remote auth endpoint" error when trying to connect to headless remote server

[aspiers]

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

1. Set up a remote VPS with access over Tailscale
2. Run npx t3 server --host "$(tailscale ip -4) on the VPS
3. Try to add the environment via the pairing URL in the T3Code desktop app:
   

Expected behavior

It should accept the URL and add the remote environment.

Actual behavior

It gives the error Failed to fetch remote auth endpoint http://100.x.y.z:3773/.well-known/t3/environment (Failed to fetch).

However, the same URL is accessible from the same desktop via curl and the browser, proving it's not a network / firewall issue.

Impact

Major degradation or frequent failure

Version or commit

0.0.17

Environment

openSUSE Tumbleweed Linux

Logs or stack traces

No new log lines appear in any of `~/.t3/userdata/logs/*.log` when I click "Add Backend".

Screenshots, recordings, or supporting files

No response

Workaround

No response

[fzimmermann89]

Similiar issue trying to connect to WSL. The server part gets the request and logs a 200 response:

[22:47:11.373] INFO (#159) http.span.41=0ms: Sent HTTP response
 http.method: GET
 http.url: /.well-known/t3/environment
 http.status: 200

[sazzy4o]

I get the same issue. If you don't care about the desktop app, the browser UI worked for me after I copied the Pairing URL and paste it into into my browser

[lnelissen-te]

I get the same issue trying to connect to my local devcontainer from the macos desktop app.
And just like sazzy4, it works fine for me in the browser.

[dansanduleac]

I wonder if if fails because of CORS.
It might work in the browser, but not from the app, because in the browser you're doing a straightforward top-level navigation, whereas from the app, it's doing a cross-origin XHR/fetch from a page, which requires a CORS preflight (that fails).

However if you're exposing it directly on the tailscale ip (and it's allowed through the firewall), that shouldn't be the issue.

~/.t3/userdata/logs/desktop-main.log will probably have more useful information.

[r1sk01]

I wonder if if fails because of CORS. It might work in the browser, but not from the app, because in the browser you're doing a straightforward top-level navigation, whereas from the app, it's doing a cross-origin XHR/fetch from a page, which requires a CORS preflight (that fails).

However if you're exposing it directly on the tailscale ip (and it's allowed through the firewall), that shouldn't be the issue.

~/.t3/userdata/logs/desktop-main.log will probably have more useful information.

CTRL+SHIFT+I > Network, the request fails because of CORS.
I'll make a patch for it real quick. ^-^

[Minoo7]

Can confirm this is CORS. Specifically, the server's CORS middleware handles OPTIONS preflight correctly but does not add Access-Control-Allow-Origin to actual GET/POST responses:

# OPTIONS preflight — correct
< HTTP/1.1 204 No Content
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, OPTIONS
< access-control-allow-headers: authorization,b3,traceparent,content-type

# Actual GET — missing CORS header
< HTTP/1.1 200 OK
< content-type: application/json
< content-length: 179
# (no access-control-allow-origin)

The desktop app loads via window.loadURL(backendHttpUrl) (origin http://127.0.0.1:PORT), so the fetch to the remote server is cross-origin. Chromium blocks the response because the GET lacks the CORS header.

Workaround: Run a Caddy reverse proxy in front of the t3 server that injects the missing headers:

:3775 {
 reverse_proxy http://<tailscale-ip>:3773
 header {
 Access-Control-Allow-Origin *
 Access-Control-Allow-Methods "GET, POST, OPTIONS"
 Access-Control-Allow-Headers "authorization, b3, traceparent, content-type"
 }
 @options method OPTIONS
 handle @options {
 respond 204
 }
}

Then use http://<tailscale-ip>:3775/pair#token=... as the pairing URL.

[matty]

Yep same issue, wanted to run headless on my Linux VM.

[fzimmermann89]

@juliusmarminge Sorry for tagging you, but you annonced this feature quite some time ago on twitter...
In all oob scenarios I try it in, the remote conenctin fails. Only Rreverse proxying to inject CORS works.
Is your test setup different? Could you have a look at this or #2036

[petem24]

+1

[ocelot2123]

+1, the only thing stopping me from using T3 Code right now

[Ouna-the-Dataweaver]

+1, I love t3code, but 95% of my dev is happening on remote machines, this breaks all flow entirely if I wanna use desktop app and not web