[Bug]: T3 Connect relay fails with TransportError on macOS nightly 20261021.3499: bundled runtime rejects public TLS chains (UNABLE_TO_VERIFY_LEAF_SIGNATURE)#23408

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

On macOS, update T3 Code Nightly to 0.1.2-nightly.20261021.3499 and restart it. No proxy, VPN or TLS inspection is in use.
Open Settings > T3 Connect.
The panel shows: "T3 Connect is out of sync. This environment is linked only to publish agent activity, so other devices cannot connect." Turning T3 Connect on fails with: "Could not configure environment relay access: Could not complete the T3 Connect relay request. The relay request failed (TransportError)."

Standalone reproduction with the bundled runtime. hosts.js calls https.get for each host in argv and prints the status or err.code:

1	const https=require("https");const hosts=process.argv.slice(2);console.log(process.versions.electron,process.versions.node,process.versions.openssl);
2	for(const h of hosts){https.get("https://"+h+"/",r=>{console.log(h,"ok",r.statusCode);r.resume()}).on("error",e=>console.log(h,"fail:",e.code))}

1	ELECTRON_RUN_AS_NODE=1 "/Applications/T3 Code (Nightly).app/Contents/MacOS/T3 Code (Nightly)" hosts.js \
2	relay.t3.codes example.com www.wikipedia.org letsencrypt.org api.github.com www.apple.com

Host	Bundled runtime (Electron 44.9.3, Node 24.22.0)	Same runtime + `NODE_USE_SYSTEM_CA=1`	System Node 24.21.0 (OpenSSL 3.5.8)
relay.t3.codes	`UNABLE_TO_VERIFY_LEAF_SIGNATURE`	302	302
example.com	`UNABLE_TO_VERIFY_LEAF_SIGNATURE`	200	200
www.wikipedia.org	`UNABLE_TO_VERIFY_LEAF_SIGNATURE`	not tested	403
letsencrypt.org	`UNABLE_TO_VERIFY_LEAF_SIGNATURE`	not tested	200
api.github.com	403 (OK)	not tested	403
www.apple.com	200	not tested	200

tls.rootCertificates.length is 121 in both the bundled runtime and system Node. Passing ca: tls.rootCertificates explicitly to https.get in the bundled runtime still fails with the same code. relay.t3.codes serves a normal public chain: CN=t3.codes <- Google Trust Services WE1 <- GTS Root R4 (cross-signed by GlobalSign Root CA).

Expected behavior

The bundled server runtime verifies normal public certificate chains, and T3 Connect can configure relay access, the same as on the previous nightly.

Actual behavior

Every relay call from the server fails TLS verification. The server trace (~/.t3/userdata/logs/server.trace.ndjson*) shows the error on AgentAwarenessRelay.publishThread, AnalyticsService.sendBatch and environment.cloud.releaseManagedTunnelOnShutdown:

1	[cause]: TypeError: fetch failed {
2	[cause]: Error: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca
3	at TLSSocket.onConnectSecure (node:_tls_wrap...)

The UI only shows "The relay request failed (TransportError)". It does not show the TLS cause, so the message points the user at their network connection.

The errors start with the restart onto 20261021.3499. Older rotated trace files from the previous build on the same machine and network have none.

Workaround: launchctl setenv NODE_USE_SYSTEM_CA 1, then quit and reopen T3 Code. NODE_OPTIONS=--use-system-ca does not work. In a test from a terminal, Electron printed "Node.js environment variables are disabled because this process is invoked by other apps". It ignored NODE_OPTIONS, but NODE_USE_SYSTEM_CA=1 still took effect.

Possible fixes:

Start the server runtime with the system CA store enabled (--use-system-ca or NODE_USE_SYSTEM_CA=1).
Find out why the bundled BoringSSL root store fails these chains in this Electron build.
Show the TLS cause in the T3 Connect error, not only TransportError.

Impact

Blocks work completely

Version or commit

0.1.2-nightly.20261021.3499

Environment

macOS 27.0.1 (arm64), desktop app, Electron 44.9.3, Node 24.22.0. No proxy and no TLS inspection.

JJulius Marminge20d ago

Checked main at 3b95e7831b on Linux x64. Ran the supplied six-host https.get probe with the Electron version pinned by this checkout, using ELECTRON_RUN_AS_NODE=1 and unsetting NODE_EXTRA_CA_CERTS:

text

1	Electron 44.4.5 / Node 24.21.0
2	relay.t3.codes 302
3	example.com 200
4	www.wikipedia.org 403
5	letsencrypt.org 200
6	api.github.com UNABLE_TO_VERIFY_LEAF_SIGNATURE
7	www.apple.com 200

The relay TLS failure did not reproduce here. This is a runtime-only comparison; the reported macOS desktop Settings flow could not be verified on this Linux VM.

Main currently pins Electron 44.4.5, whereas the report identifies 44.9.3 / Node 24.22.0. Does the failure persist on the current nightly? Please include that build's Electron/Node versions and the same host-probe results with NODE_USE_SYSTEM_CA unset. This would distinguish a runtime/build-specific regression from one still present in the current build.

Llakshaychopra20d ago

Still reproduces on macOS arm64 with 0.1.2-nightly.20261021.3499 (Electron 44.9.3, Node 24.22.0), probe run with NODE_USE_SYSTEM_CA and NODE_EXTRA_CA_CERTS unset:

text

1	relay.t3.codes UNABLE_TO_VERIFY_LEAF_SIGNATURE
2	example.com UNABLE_TO_VERIFY_LEAF_SIGNATURE
3	www.wikipedia.org UNABLE_TO_VERIFY_LEAF_SIGNATURE
4	letsencrypt.org UNABLE_TO_VERIFY_LEAF_SIGNATURE
5	api.github.com 403
6	www.apple.com 200

Note: 3b95e7831b pins electron 44.9.3 in apps/desktop/package.json, not 44.4.5, so the Linux run above probably used a stale local Electron. The 44.4.5 run also failed on api.github.com, which suggests the root store differs between Electron builds. The latest nightly 20261022.3512 still pins 44.9.3. I did not run it yet.

JJulius Marminge20d ago

Confirmed the version mismatch in the previous triage comment: 3b95e7831b pins Electron 44.9.3; the installed 44.4.5 runtime used for that attempt was stale.

Downloaded Electron 44.9.3 on Linux x64 and verified process.versions reports Electron 44.9.3 / Node 24.22.0. With NODE_USE_SYSTEM_CA and NODE_EXTRA_CA_CERTS unset, the supplied six-host probe gets 302/200/403/200/UNABLE_TO_VERIFY_LEAF_SIGNATURE/200 in the reported host order. Adding --use-system-ca changes api.github.com to HTTP 403 (TLS succeeds); the other results stay the same. Runtime transcript.

The public-chain verification failure reproduces in the matching bundled runtime, with a different affected host on Linux. The exact macOS Settings → T3 Connect failure remains unverified here.

JJulius Marminge20d ago

Candidate fix: #23424. It enables system CA trust for the bundled desktop backend through its startup arguments. The regression test fails before the change and all 18 focused tests pass after it. Matching Electron 44.9.3 Linux runtime evidence confirms certificate failure → HTTP response with the flag. Packaged desktop startup and the reported macOS relay flow remain unverified; the PR records those limits.

Ddhruvkelawala17d ago

This also breaks images in PR descriptions. Still reproduces on 0.1.3-nightly.20261023.3579 (Electron 44.9.3, Node 24.22.0, macOS 27.0.1 arm64).

Images in private-repo PR descriptions don't load in the PR panel. The panel recognizes the GitHub image links and the backend fetches them with the GitHub token, but that fetch fails TLS. Every GitHubMediaFetch.githubMediaResponse span in my server traces fails this way (30 requests across two private repos):

1	HttpClientError: Transport error (GET https://raw.githubusercontent.com/<owner>/<repo>/<branch>/<file>.png)
2	[cause]: TypeError: fetch failed {
3	[cause]: Error: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca

fetch probe, run with ELECTRON_RUN_AS_NODE=1 for the bundled runtime:

URL	Bundled runtime	Same + `NODE_USE_SYSTEM_CA=1`	System Node 24.22.1
`https://raw.githubusercontent.com/github/gitignore/main/Node.gitignore`	`UNABLE_TO_VERIFY_LEAF_SIGNATURE`	200	200
`https://objects.githubusercontent.com/`	`UNABLE_TO_VERIFY_LEAF_SIGNATURE`	404 (TLS OK)	404 (TLS OK)
`https://github.com/`	200	200	200
`https://api.github.com/`	200	200	200

raw.githubusercontent.com serves CN=*.github.io <- Let's Encrypt YR1 <- ISRG Root YR (cross-signed by ISRG Root X1).

I also sent the request the backend sends for a private image (Bearer gh token, accept-encoding: identity) from the bundled runtime. It fails without NODE_USE_SYSTEM_CA=1 and returns 200 image/png with it. The media proxy runs in the bundled backend, so the --use-system-ca startup argument in #23424 should fix PR images as well.

NNate Glasby12d ago

The bundled-runtime TLS failure is still reproducible on macOS arm64 with desktop version 0.1.6-nightly.20261029.3892, bundled Node v24.22.1.

While linking a remote environment, the HTTPS relay fallback failed. The server trace showed:

text

1	unable to verify the first certificate

An isolated fetch test using the installed app’s bundled runtime reproduced UNABLE_TO_VERIFY_LEAF_SIGNATURE. The same request succeeded with HTTP 200 using either standalone Node or the bundled runtime with NODE_USE_SYSTEM_CA=1.

I worked around the linking failure using the remote machine’s Tailscale .ts.net hostname. I did not apply the certificate setting to the running app.

Investigated with Codex, GPT-6.1-sol.