6 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5	9297020688	fix: open host URLs with a clean environment (triple-c#34) ... On Linux the app ships as a single AppImage, and the AppImage environment leaks into everything it spawns. linuxdeploy's AppRun, linuxdeploy-plugin-gtk and our own wayland fallback hook all export LD_LIBRARY_PATH, GTK_PATH, GIO_MODULE_DIR and friends pointing inside $APPDIR, and main.rs sets WEBKIT_DISABLE_DMABUF_RENDERER process-wide for the webview. A browser that is already running shrugs this off, because xdg-open just hands the URL to the existing process. A cold-launched one inherits the lot and dies before painting -- with xdg-open still exiting 0, which is why this looked like the button doing nothing at all. `url_open` captures a pristine snapshot of the environment in main() before any mutation runs, then hands children a repaired copy: a saved original is restored where one exists, otherwise the process-start value is restored where we changed it, otherwise only the colon-separated entries that live under $APPDIR are dropped and the user's own are kept. Outside an AppImage it is a no-op. The command re-validates the URL in Rust rather than trusting the frontend, because the URL originates in an untrusted container: http/https only, no embedded credentials, no control characters or whitespace, length capped, ASCII asserted before it reaches execvp, and error messages never echo the input. Spawning is Command with explicit args and never a shell, trying xdg-open then gio open. No portal. org.freedesktop.portal.OpenURI would pull in a D-Bus client stack for one call on the one platform where we ship self-contained, and it only helps where a portal is running -- the same case where xdg-open already works once the environment is clean. `gio open` as a second candidate recovers most of the missing-MIME-association case for free. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 10:08:20 -07:00
shadowdaoandClaude Opus 5	a3bdf6f4da	Let the host's libwayland-client win in the AppImage ... The AppImage came up blank on CachyOS with `Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...`, and the DMA-BUF workaround already in `main.rs` did not help — verified by finding the flag compiled into the shipped 0.4.19 binary, where it runs unconditionally on Linux. It is a different fault with the same error text. linuxdeploy bundles `libwayland-client.so.0` as a GTK dependency and `AppRun.wrapped` puts the bundled directory ahead of the host's, so the host's Mesa resolves against our copy. `libEGL_mesa.so.0` — the driver libglvnd's `libEGL.so.1` dlopens — has a hard DT_NEEDED on that library, so when its symbols will not resolve the driver never loads, glvnd is left with none, and `eglGetDisplay` reports no display. That is why `GDK_BACKEND=x11` does not dodge it, and why the symptom is a bad-parameter error rather than a link failure. Bisected on the reporter's machine against the released artifact — removing `libwayland-client.so.0` from the AppDir cleared the abort, while removing `libwayland-egl` or `libepoxy` did not. The bundled copy (Ubuntu 22.04, wayland 1.20) is missing eleven symbols their wayland 1.26 exports, including `wl_proxy_get_display`, `wl_proxy_get_queue`, `wl_display_create_queue_with_name` and `wl_fixes_interface`. Bundling a newer wayland would defer this, not fix it: the floor is set by the host's Mesa, which updates independently of our releases, so any version we pick is one release away from being too old again. This is a host-coupled library like libGL and libdrm — the only correct version is the host's. So the copy is demoted rather than deleted. It moves off the loader path into `usr/lib/wayland-fallback`, and a hook adds that directory back only when the host has no libwayland-client of its own — so a host without one still starts. The ordering is safe because `AppRun.wrapped` appends the inherited LD_LIBRARY_PATH after its own entries, making the hook a fallback and never an override. AppRun sources hooks by name rather than globbing, so it is patched to source this one. X11-only hosts are unaffected: libwayland-client is a package dependency of Mesa and GTK, so it is present even on a machine with no display server at all — confirmed on a headless container with neither DISPLAY nor WAYLAND_DISPLAY set. And the AppImage already runs as an X11 client everywhere, since linuxdeploy's own hook forces GDK_BACKEND=x11. Verified against the real 0.4.19 artifact rather than a synthetic AppDir: it repacks, the binary and AppRun survive, and both hook branches were exercised — host-has-it leaves LD_LIBRARY_PATH untouched, and a debian:12-slim container with no wayland at all engages the fallback. The comment in `main.rs` quoted this exact error as one the DMA-BUF flag fixes. That claim sent this investigation down the wrong path first, so it is corrected rather than left to do it again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 16:57:51 -07:00
shadowdaoandClaude Opus 5	3a49a67c1f	Fix terminal input reordering and Linux terminal rendering ... Two separate defects behind the same report: typing in a container terminal is sluggish on Linux, and a backspace can land *after* the characters typed behind it. The web terminal was the control that separated them. It shares the Docker exec, the PTY, `exec_manager`, the input channel and its serial writer task, and xterm.js itself — and it does not exhibit either symptom. Only three things differ, and each accounts for part of the report. **Input ordering.** Every keystroke was its own `invoke("terminal_input")`. That command is `async`, so Tauri spawns each one as an independent task, and those tasks then race for the session mutex in `ExecSessionManager::send_input` — nothing preserved the order the bytes were typed in. The serial writer downstream cannot help, because the order is already lost before anything reaches the channel. The web terminal gets ordering for free by awaiting `send_input` inline in a single WebSocket reader loop. `useTerminal` now holds a per-session queue: one write in flight at a time, the next only after the previous resolves. Anything typed meanwhile coalesces into the next chunk, which also collapses a burst of typing into a couple of IPC round trips rather than one per key. The queue is module scope, not hook scope, because `useTerminal()` is called from several components — a per-hook queue would leave speech-to-text, image paste and typing racing each other. Each caller's promise still settles only when its own bytes have gone, so `await sendInput(...)` keeps its meaning. **The DMA-BUF escape hatch did not exist.** `apply_webkit_wayland_workaround` left any pre-set value alone, including `0`, on a stated assumption that WebKitGTK reads the variable as a boolean. It reads presence, so `WEBKIT_DISABLE_DMABUF_RENDERER=0` disabled DMA-BUF exactly like `=1`, and no value a user could set got the accelerated path back. `0`/`false`/`no`/empty now remove the variable, which is the only thing WebKitGTK reads as enabled. The default is unchanged: unset still means disabled on Linux. **WebGL does not degrade to canvas here.** The comment on that workaround assumed `@xterm/addon-webgl` would fall back to the canvas renderer once DMA-BUF was off. Its constructor throws only when WebGL is *absent*, and with DMA-BUF disabled WebGL is still present — served by software rasterisation. So the addon loads and every frame is rendered on the CPU, slower than the canvas renderer it was assumed to fall back to. `AppSettings::terminal_gpu_ rendering` decides whether it loads at all: `None` is auto (on for macOS and Windows, off on Linux), `Some(_)` forces it either way from Settings → Terminal. `Option<bool>` rather than `bool` so the zero value means "we choose" instead of pinning every existing settings file to one answer. Verified: 643 frontend tests and 530 Rust tests pass, clippy clean, secret scan clean. The Linux rendering half needs confirming on a real desktop — neither symptom reproduces in a headless container. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ApLYH6ybHwQFkMCtKuHrrV	2026-08-28 12:51:18 -07:00
shadow-testandClaude Sonnet 5	8f62949902	Correct two overclaims in the Wayland workaround's comment ... Review found: "nothing this app's UI depends on" is backwards — the terminal's @xterm/addon-webgl renderer is exactly the GPU compositing path this setting disables, it just degrades gracefully (the addon's own construction already handles WebGL being unavailable) rather than crashing. And the "not simply Wayland vs X11" justification for going unconditional doesn't hold up: WAYLAND_DISPLAY is exported into an XWayland client's environment too, so gating on it would have caught that case as well — the real reason to go unconditional is that there's no reliable heuristic for the thing that actually matters (which Mesa/driver/compositor combination is affected), not that the naive gate misses XWayland specifically. Also noted, not changed: the env var leaks to whatever the app spawns afterwards (a cold-launched default browser via xdg-open), and the "=0 re-enables it" parenthetical isn't verified against WebKitGTK's own source, so softened to say what's actually guaranteed (an already-set value is left alone) rather than assume presence-vs-boolean parsing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 10:57:45 -07:00
shadow-testandClaude Sonnet 5	6354cb42b2	Work around WebKitGTK's EGL crash on Wayland (triple-c#34) ... Reported on CachyOS/Arch with Wayland: the app aborts immediately with "Could not create default EGL display: EGL_BAD_PARAMETER. Aborting." printed straight to stderr by WebKitGTK's own C code, before Triple-C's own logging even gets a chance to say anything useful about it. This is WebKitGTK's DMA-BUF renderer (its default accelerated-compositing path since 2.42) failing on some Mesa/driver/compositor combinations. Set WEBKIT_DISABLE_DMABUF_RENDERER=1 unconditionally on Linux before the Tauri builder runs, which is where GTK/WebKitGTK actually read it — there's no reliable way to detect the affected combination ahead of time (reports of this exact failure exist under XWayland too, not just pure Wayland sessions), and WebKitGTK's fallback compositing path costs some rendering performance this app's UI doesn't need. Left alone if a user has already set the variable themselves. Does not address the other two things filed under the same issue (links not opening on the host, and a request for a native Arch/CachyOS package) — those need more information / are a separate scope, respectively. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 10:45:24 -07:00
shadow-testandClaude Opus 4.6	97a0745ead	Initial commit: Triple-C app, container, and CI ... Tauri v2 desktop app (React/TypeScript + Rust) for managing containerized Claude Code environments. Includes Gitea Actions workflow for building and pushing the sandbox container image, and a BUILDING.md guide for manual app builds on Linux and Windows. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-02-27 04:29:51 +00:00