`Access-Control-Allow-Origin` missing from responses since 0.0.34 — desktop app cannot connect to a remote environment on a separate HTTPS origin

[epavlenko]

Summary

Since 0.0.34 the server answers the CORS preflight correctly but omits Access-Control-Allow-Origin from the actual response. Any browser-context client whose origin differs from the server's therefore discards the response, and the desktop app never gets past Failed to connect. Reconnecting....

0.0.33 is the last version that sends the header. Rolling the server back to 0.0.33 — changing nothing else — restored the desktop client immediately.

Environment

• Server: headless t3 serve --host <tailnet-ip> --port 3010, Linux x64, Bun runtime
• Reached from the desktop over a separate HTTPS origin via Tailscale Serve
  (https://<host>.ts.net:8445 → http://<tailnet-ip>:3010), valid Let's Encrypt cert
• Desktop app: macOS, tested at 0.0.33, 0.0.35, 0.0.36, 0.0.37 — all fail against a 0.0.34+ server

Reproduction

t3 serve --host 127.0.0.1 --port 3099 --base-dir /tmp/t3probe

curl -sD- -o/dev/null -H 'Origin: https://app.t3.codes' \
 http://127.0.0.1:3099/.well-known/t3/environment | grep -i access-control

Server version	Released	Access-Control-Allow-Origin on GET
0.0.33	2026-08-10	*
0.0.34	2026-08-26	absent
0.0.35	2026-08-27	absent
0.0.36	2026-08-29	absent
0.0.37	2026-08-31	absent
0.0.38-nightly.20260831	2026-08-31	absent

The preflight still looks right on 0.0.37:

$ curl -sD- -o/dev/null -X OPTIONS -H 'Origin: https://app.t3.codes' \
 -H 'Access-Control-Request-Method: GET' .../.well-known/t3/environment
HTTP/2 204
access-control-allow-origin: *
access-control-allow-methods: GET, POST, OPTIONS
access-control-allow-headers: authorization,b3,traceparent,content-type,dpop
access-control-max-age: 600

The same GET that lacks the header returns 200 with the expected body, so this is purely a response-header regression. Reproduced on /.well-known/t3/environment, /api/auth/session and /health, and with every Origin value tried (https://app.t3.codes, file://, app://-, null, http://localhost:5173, the server's own origin).

Symptom in the desktop app

Provider settings are unavailable
Failed to connect. Reconnecting... Reason: Failed to fetch remote environment endpoint
https://<host>.ts.net:8445/.well-known/t3/environment
(HttpClientError: Transport error (GET https://<host>.ts.net:8445/.well-known/t3/environment))

What rules out a network or TLS problem:

• curl -v from the same Mac, at the same moment, completes the handshake and returns HTTP/2 200 with the descriptor JSON; cert verifies, ALPN negotiates h2.
• The iOS app connected to the same 0.0.35 server successfully while the desktop could not. A native client does not enforce CORS; curl does not either. Only the browser-context client fails.
• Server-side /api/auth/clients showed no connection attempt from the desktop after the upgrade, while the stored bearer token was still valid for another two weeks.

Why it may have gone unnoticed

The common setup is a desktop app talking to a server on the same machine over loopback, where the request is not cross-origin. It only bites when the environment is remote and published on a different origin — the documented Tailscale Serve setup in docs/user/remote-access.md.

Expected

Responses carry Access-Control-Allow-Origin (as 0.0.33 did), so a remote environment on its own HTTPS origin stays reachable from browser-context clients.

Failing that, a documented way to configure allowed origins would be enough — there is no server setting for it today.

[derektrimm]

I dug into this and believe I have the mechanism. It is not a CORS-code change: the CORS configuration and middleware wiring are byte-identical between 0.0.33 and 0.0.34. The regression traces to the 0.0.34 CLI bundling change (#5877): dist/bin.mjs now inlines effect, while @effect/platform-bun stays external. When the server runs under Bun, BunHttpServer loads a second copy of effect from node_modules.

Effect's CORS middleware answers OPTIONS preflights inline (which is why preflight still looks right), but it attaches headers to actual responses through a pre-response handler stored in a module-level WeakMap that the platform server's toHandled later reads. With two effect instances, the bundled copy writes the handler into its WeakMap and the node_modules copy reads its own and finds nothing, so Access-Control-Allow-Origin never lands on the real response. Node-run servers are unaffected because @effect/platform-node is bundled into the same graph (single instance), which also explains why the server test suite (NodeHttpServer.layerTest, one in-process effect) cannot reproduce this.

Supporting evidence:

• The published 0.0.37 dist/bin.mjs contains effect's inlined pre-response-handler code and dynamically imports @effect/platform-bun/BunHttpServer, with both effect and @effect/platform-bun present as runtime dependencies - two resolvable copies.
• In 0.0.33 effect was external, so the CLI and platform-bun shared one instance - matching your version bisect exactly.

If the mechanism is right, everything else that rides the pre-response handler is silently broken on Bun-run servers too: gzip/deflate compression and the auth refresh / DPoP / cloud credential headers. Mechanism confirmed in source; not yet measured on a live Bun process. A quick check is curl -H 'accept-encoding: gzip' -sD- .../.well-known/t3/environment on a Bun-run 0.0.34+ server - it should come back uncompressed.

Possible fix shapes, in case it helps triage: (1) bundle @effect/platform-bun and @effect/sql-sqlite-bun too, leaving only bun: protocol specifiers external, so a single effect graph exists; (2) return effect and @effect/platform-* to runtime-external, which is correct but walks back part of #5877's install-time win; (3) defensively set the CORS headers directly on the response instead of via the pre-response handler - mitigates this issue but leaves compression and the auth headers broken. Happy to put up a PR for whichever direction the maintainers prefer.

[epavlenko]

Ran your check on a live server. The mechanism holds, and both of its predictions reproduce.

Same box, same published 0.0.37 build, only the runtime differs. Node install via npm (so node-pty compiles), Bun install via bun add --ignore-scripts:

t3 serve --host 127.0.0.1 --port 3099 --base-dir /tmp/t3probe # under bun
t3 serve --host 127.0.0.1 --port 3098 --base-dir /tmp/t3probe # under node

curl -sD- -o/dev/null -H 'Origin: https://app.t3.codes' \
 http://127.0.0.1:<port>/.well-known/t3/environment
curl -sD- -o/dev/null -H 'accept-encoding: gzip' http://127.0.0.1:<port>/

0.0.37 run under	access-control-allow-origin	GET /
Bun	absent	content-length: 19884, no content-encoding
Node	*	content-length: 5017, content-encoding: gzip, vary: Accept-Encoding

So compression is broken on Bun exactly as you predicted — 4x larger responses — and it rides the same pre-response handler. Worth noting for anyone else testing this: the small JSON endpoint is not a useful probe for the compression half, it comes back uncompressed on both runtimes (517 bytes, presumably under the minimum size). The difference only shows on a larger response such as /.

One clarification to the report: the trigger is running the server under Bun, not the version alone. My original bisect looked version-shaped because this server has always been Bun-run — it was installed with --ignore-scripts back when the machine had no C toolchain and node-pty could not build, and the Bun PTY adapter made that work. 0.0.33 was fine under Bun because effect was still external there.

Fix on my side was to reinstall under Node and drop the version pin; 0.0.37 now serves the desktop client normally, with CORS and gzip both working. Leaving the issue open since Bun-run servers are presumably still a supported configuration — docs/user/install.md does not say otherwise, and bun add t3 is the natural install on a machine without a compiler.