`but remote`: embedded frontend crashes in browser (Tauri APIs undefined)

[artile]

Summary

The nightly but remote CLI serves the embedded SvelteKit frontend over HTTP, but the bundle assumes a Tauri runtime. In a plain browser window.__TAURI_INTERNALS__ and window.__TAURI_OS_PLUGIN_INTERNALS__ are undefined, so the app crashes during mount and the user sees a white screen.

Environment

• but --version: but 0.5.1997 (nightly 0.5.1997-2992, Linux x86_64 binary from releases.gitbutler.com)
• Server: but remote --local --port 6978 (also reproduces with the Cloudflare quick-tunnel mode)
• Client: any modern browser (tested Chromium via agent-browser) over SSH -L 6978:localhost:6978
• OS: Ubuntu 24.04 (Linux 6.8)

Steps to reproduce

1. but remote --local --port 6978 from a GitButler project directory
2. Forward the port to another host (e.g. ssh -L 6978:localhost:6978 <vps>) or hit it directly in a browser
3. Open http://localhost:6978/

Expected

The embedded GitButler UI renders and the project is usable from the browser (the whole point of but remote).

Actual

Blank white page. Console:

TypeError: Cannot read properties of undefined (reading 'platform')
  at ... /_app/immutable/chunks/CZlikwsS.js:5:5791
TypeError: Cannot read properties of undefined (reading 'invoke')
  at ... /_app/immutable/chunks/B7_bfKp9.js:1:20253
  at ... /_app/immutable/entry/app.CWh5gVUS.js:2:1187

The server itself is healthy:

• GET / → 200 (HTML shell)
• GET /_app/immutable/entry/start.*.js → 200
• GET /_app/env.js → 200
• GET /api → 200
• CORS allow-origin http://localhost:6978, access-control-allow-credentials: true
• CSP connect-src includes ws://localhost:6978 — WS path is fine

So it's purely a frontend problem: the bundle that but-server embeds is the Tauri-targeted apps/desktop/build/, which calls window.__TAURI_OS_PLUGIN_INTERNALS__.platform and window.__TAURI_INTERNALS__.invoke unconditionally. Without polyfills for a browser context, the SvelteKit app throws on mount and nothing else renders.

Suggested fixes

• Guard the __TAURI_* accesses behind a runtime check and fall back to an HTTP/WebSocket transport when running under but remote (i.e. when served from the embedded server rather than Tauri).
• Or build a separate "browser" variant of the frontend for embedded-frontend that ships browser-mode transports, and have but-server serve that one.
• At minimum, document that but remote currently only works if the frontend is launched via Tauri, so users don't go chasing tunnel/CORS/Tailnet red herrings.

Happy to test a fix.

[Byron]

Thanks a lot for reporting.

And while this is definitely a hidden subcommand, I can imagine one can easily find it accidentally, given how important the git remote command is.

Let me forward you to @mtsgrd who will know what to do.

[krlvi]

Hey @artile just a heads up that this is indeed a hidden function that is deliberately not compiled in the release version of the app. Cool that you found it, but it's very much an experiment we are running internally

[Byron]

I think the issue is that it's easy enough to discover this command and then be surprised, and maybe that tells us we shouldn't compile it in at all or rename it to something undiscoverable.

[krlvi]

In general, for the use case of connecting to a remote environment I think we will do something like what VSCode does so there will be iteration on this front

[krlvi]

I agree about potentially not including this in the nightly / or adding a subcommand like "but experimental "