OR-326 Add the Linux desktop app as a self-updating AppImage by myles332 · Pull Request #445 · alphaXiv/OpenResearch

myles332 · 2026-09-25T21:27:28Z

Phase 3 of the desktop app, stacked on #439 (Windows) → #438 (macOS); retarget to main once those merge. PDF previews depend on #444 (PDF.js), since WebKitGTK has no PDF viewer.

What changes

desktop cargo feature (Linux only): optional tao, wry, gtk and png, so the static musl CLI builds stay GTK-free. build.rs sets cfg(desktop_app) for macOS, Windows, and Linux with the feature.
orx app on Linux, started by the AppImage's AppRun and sharing the Windows entry point (APP_ARG / launched_with_app_arg):
- the webview goes in the window's GTK box; closing the window quits; the icon is an embedded PNG
- downloads ask where to save with a GTK dialog on the main thread (rfd's GTK backend deadlocks against tao)
- the login shell's PATH and related variables are adopted after the single-instance claim
- one instance at a time via a Unix socket in $XDG_RUNTIME_DIR; a second launch shows the running window
- startup errors show through zenity or kdialog, and on stderr
Dock and app grid: the program name is OpenResearch (so the window class is too), and each launch writes ~/.local/share/applications/openresearch.desktop plus its icon, pointing at the AppImage's current path. TryExec hides the entry once the AppImage is deleted. Without it GNOME shows a gear named orx.
Window visibility (all platforms): the window still waits for the page to load, but now also appears 15 s after the server is up if loading never finishes (logged to stderr), and whenever a relaunch (Linux/Windows) or a Dock click (macOS) asks for it.
Host environment: AppRun saves the session's values of the variables it and the GTK hook override as ORX_HOST_*. The browser, file manager, editors, folder picker, dashboard terminals, agents and the update relaunch get them back, so host programs don't load the image's GTK modules and schemas. Relative project paths and the folder picker anchor to home, not the read-only mount.
AppImage (scripts/build-linux-appimage.sh, linux/):
- checksum-pinned linuxdeploy, linuxdeploy-plugin-gtk, appimagetool and type2 runtime
- WebKitGTK bundled Tauri-style (/usr rewritten to ././ in libwebkit2gtk, AppRun runs from $APPDIR/usr); WebKit's helper processes get an RPATH into the image so they never load the host's libraries
- GLib's TLS module (libgiognutls) is bundled, and GIO_MODULE_DIR points only at the image's modules: the host's are built against a newer GLib than the bundled one
Self-update: InstallChannel::AppImage (appimage in the dashboard). updates/linux_app.rs reads linux-app.json (one sha256 per architecture), verifies the download, and renames it over the old file; production builds only. Restart execs the new $APPIMAGE on the same port. The macOS manifest fetch moved into a shared fetch_app_manifest.
CI: linux app (x86_64|aarch64) on ubuntu-22.04 / ubuntu-22.04-arm: clippy and tests with --features desktop, release build, packaging, then a smoke test with WebKitGTK removed from the runner. It passes only when the dashboard answers, a visible OpenResearch-class window appears without the load fallback, the desktop entry points at the AppImage, and every WebKit helper runs from and maps libwebkit2gtk from the image and no host GIO modules. Uploaded as openresearch-linux-<arch>-appimage.
Release: release-linux-app.yml builds both architectures from the release commit and attaches the AppImages, then linux-app.json; gated on LINUX_APP_ENABLED, with write permission only in the publish job.
Docs: new docs/linux.md.

Known gaps

No audio or video previews (GStreamer isn't bundled).
On Wayland the app runs through XWayland (the GTK plugin sets GDK_BACKEND=x11).
HTTPS pages inside the window fail certificate checks on Fedora and openSUSE, whose CA bundle lives elsewhere; the dashboard itself is local HTTP.
Neither the AppImage nor its manifest is signed; trust rests on the release's sha256, as for the CLI installer.

Test plan

🤖 Generated with Claude Code

The OpenResearch.app now hosts the dashboard in a native window (tao + wry WKWebView) instead of handing it to the user's browser. It adds a standard menu bar, save panels for downloads, a native window.confirm panel, and a Cmd+Q that flushes workspace state and shuts the server down cleanly. Pop-ups open in the system browser (http/https/mailto only). The app now prefers port 4792 so the window's localStorage survives relaunches. The Dock-click tab-focus script, its Apple-events entitlement, and the SSE client counter it relied on are removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Adds the Windows desktop app. A small GUI-subsystem OpenResearch.exe (windows/launcher) starts the orx.exe beside it as `orx app` in a hidden console, so orx and the git, shell, and agent processes it runs share one invisible console instead of each flashing a window. `orx app` shares the macOS window code in src/commands/app.rs: WebView2 window, pop-ups to the system browser, save panel, page-load reveal, and port 4792. On Windows, closing the window quits, a second launch focuses the running window (named mutex + event), and the taskbar groups the window with the Start menu shortcut. An update restart relaunches as the app on the same port. Quit on both platforms now goes through up::request_shutdown instead of a self-sent SIGTERM. An Inno Setup script builds a per-user OpenResearch-Setup.exe with a Start menu entry and a WebView2 bootstrap. CI builds it as an artifact, and release-windows-app.yml attaches it to releases once WINDOWS_APP_ENABLED is set. The icon is embedded via embed-resource. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

- The focus listener captured its bare HANDLE (edition 2021 disjoint capture) instead of the Send wrapper, which failed to compile on Windows. - An orx.exe away from the CLI installer's prefix, like the app's, is now Portable even when the installer's receipt exists, so it can update itself. - Single instance creates its event before the mutex; the launcher hands its foreground rights to orx.exe. - Focus requests and server readiness are ignored while quitting, and focus waits for the first load. The save dialog is owned by the window. - Telemetry counts an app start only after the instance claim. - The installer reports a failed WebView2 bootstrap and shows progress. - Icon embedding now fails the build if no resource compiler is found. - CI format-checks the launcher; the release job drops an unpinned action. - Docs: maintainer notes for the release gate, two known gaps, and wording. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

- Keep the macOS save panel free-floating: only Windows gets the window as its owner, since a parent makes rfd show a sheet on macOS. - Treat the WebView2 bootstrap as failed unless the runtime is then present. - Move the UTF-16 helper out of the single-instance module, and bind the kernel object names before the mutex call that GetLastError follows. - Docs and a dead_code reason. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A `desktop` cargo feature builds the windowed app on Linux (glibc, WebKitGTK), leaving the static musl CLI builds untouched. build.rs sets cfg(desktop_app) for macOS, Windows, and Linux with the feature, replacing the macOS-or-Windows gates. The AppImage's AppRun starts `orx app`, sharing the Windows entry point: the webview is built into the GTK window's box (X11 and Wayland), closing quits, a Unix socket in XDG_RUNTIME_DIR keeps one instance and focuses it, and the login shell's PATH is adopted as on macOS. scripts/build-linux-appimage.sh bundles WebKitGTK with pinned linuxdeploy, its GTK plugin, and appimagetool, copying WebKit's helper processes and rewriting libwebkit2gtk's /usr paths to ././ so they resolve inside the image. CI builds x86_64 and aarch64 AppImages on Ubuntu 22.04 and smoke-tests each under Xvfb; release-linux-app.yml attaches them with linux-app.json once LINUX_APP_ENABLED is set. The AppImage updates itself (InstallChannel::AppImage, updates/linux_app.rs): a sha256-checked download renamed over the file, production builds only, and Restart execs the new AppImage on the same port. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

From review of the Linux desktop app: - Downloads froze the app: rfd's GTK backend runs its dialog on a thread of its own, which waits forever on the main context tao holds. The save dialog is now a gtk::FileChooserDialog run on the main thread. - The bundled WebKit helpers found their libraries only beside themselves, so they loaded the host's WebKit or none. They now get an RPATH to the image's usr/lib, and linuxdeploy no longer makes stray copies of them. - The GTK hook's variables reached every host program orx opens. AppRun now saves the session's values and orx hands them back to xdg-open, the folder picker, error dialogs, and agents. - The smoke test now runs after WebKitGTK is removed from the runner and checks that each WebKit helper runs, and loads libwebkit2gtk, from the image; cleanup kills the app's whole process group. - Startup failures now reach stderr and a zenity or kdialog dialog. - The tools and the AppImage runtime are pinned by sha256, and only the release job that publishes can write to the release. - Smaller fixes: the shell probe runs after the single-instance claim and falls back to /bin/sh; APPDIR is canonicalized and must not be empty or root; relative project paths resolve against home inside the image. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Restore the host GTK variables before an update relaunches the AppImage, so the new AppRun doesn't save the old image's values as the session's, and in the dashboard's terminals. Share one APPDIR containment check between the update channel, relative project paths, and the folder picker, which now keeps a terminal `orx up`'s working directory. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Pick the relaunch target with the same APPDIR check as the update channel, so an `orx app` started from the app's terminal restarts itself. Hand the shell probe the session's GTK settings, harden the smoke test's helper checks and cleanup, and bring the docs up to date. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Its mount paths aren't absolute on Windows, which has no AppImage anyway. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

On a UTM VM the Linux app ran with no window: it stays hidden until the page finishes loading, and that never happened. Show it 15 seconds after the server is up regardless, say so on stderr, and have the smoke test fail if that fallback fires or no window appears. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…st modules GNOME shows an unmatched window as a gear named after its class, so name the program OpenResearch and have each launch install a desktop entry and icon pointing at the AppImage (TryExec hides it once the file is gone). Bundle GLib's TLS module and set GIO_MODULE_DIR to the image's, so the bundled GLib stops loading the host's modules, built against a newer one. A second launch now shows the window even before the page loads, so a stuck instance can't swallow it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Write the desktop entry only from the AppImage's own orx (shared with the update relaunch), keep a session's GIO_EXTRA_MODULES off the bundled GLib, mark a Dock-reopened macOS window as shown so the load fallback can't reopen it, close a race in the smoke test, and note the Fedora and openSUSE TLS gap. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

# Conflicts: # Cargo.lock # ui/dist/assets/index-DLDRL7rV.js # ui/dist/assets/index-UAhw--Xc.js # ui/dist/assets/index-yT9oNk64.js # ui/dist/index.html

…myles/desktop-app-linux # Conflicts: # ui/dist/assets/index-DLDRL7rV.js # ui/dist/assets/index-Df-zvt4S.js # ui/dist/assets/index-ZrkI6iDM.js # ui/dist/index.html

# Conflicts: # Cargo.lock # Cargo.toml # src/commands/app.rs # src/updates.rs

If the dashboard never finishes loading, show the window 15 seconds after the server is up and say so on stderr; a relaunch (or a Dock click on macOS) also shows it before the page loads. The installer and uninstaller now check the app's single-instance mutex and ask the user to close it, rather than replacing files under a running app and skipping its shutdown path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… launch without WebView2 Move the file a download replaces aside and restore it if the download fails or is cancelled (WebView2's flyout can cancel), rather than deleting it up front. The installer no longer offers to start OpenResearch when the WebView2 Runtime is still missing, since the window could not open. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…myles/desktop-app-linux # Conflicts: # src/commands/app.rs

# Conflicts: # Cargo.toml # build.rs # src/commands/app.rs # src/commands/up.rs # src/main.rs # src/telemetry.rs # src/updates.rs # windows/launcher/src/main.rs

greptile-apps · 2026-09-28T19:40:21Z

Confidence Score: 2/5

[High risk] Adds Linux desktop app with self-update and CI/release workflows.

The PR should not merge until concurrent launches cannot create duplicate instances and a shared temporary-directory socket cannot prevent legitimate launches.

Findings

Concurrent launches lose socket ownership ▶
Shared socket can block launches ▶
Updates replace symlinks instead ▶
Interrupted updates leave large files ▶
Large downloads fill memory ▶

Fix with agent prompt

### Issue 1
src/commands/app.rs:380-381
If two AppImages launch together after a cold start or update restart, both can fail the initial socket connection. One can bind the socket, then the other can remove its pathname and bind a new socket. Both apps keep running, and later launches can no longer focus the first window. The single-instance claim needs to prevent another launch from removing a newly bound socket.

### Issue 2
src/commands/app.rs:361-367
If `XDG_RUNTIME_DIR` is unset, the app uses a predictable socket name in the shared temporary directory. Another local user can bind that name first; the app then treats the connection as an existing instance and exits without opening a window. Use a user-owned socket location and verify ownership before accepting the connection.

**How this was verified:** The fallback uses a predictable pathname in the shared temporary directory, and any successful connection causes the app to exit its launch path.

### Issue 3
src/updates/linux_app.rs:175
If the AppImage was launched through a symlink, this rename replaces the symlink rather than its target. The updater reports success and the launcher path runs the new version, but the AppImage at the intended installation path remains old. Resolve the target or reject symlinked installs before updating.

### Issue 4
src/updates/linux_app.rs:125-132
An interrupted background update can leave a full `.OpenResearch-update-*.AppImage` beside the installation. Each attempt uses a new filename, while cleanup only handles an error returned by the current attempt, so repeated interruptions consume disk space. Sweep leftovers before staging another update, as the macOS updater does.

### Issue 5
src/updates/linux_app.rs:106-112
This passes the WebKit-bundled AppImage through `fetch_release_asset`, which holds the entire download in memory before it is verified and written to disk. That adds substantial peak memory use and may prevent updates on memory-constrained desktops. Stream the download into the staging file while calculating its checksum.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds a Linux desktop AppImage, packaging and release workflows, desktop integration, and a self-update channel while preserving the default GTK-free CLI build.

The Linux instance claim needs atomic and private socket ownership.
AppImage updates need safer handling of symlinked installs, interrupted staging, and large downloads.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[AppImage runtime] --> B[AppRun]
  B --> C[orx app]
  C --> D[Unix socket claim]
  C --> E[Dashboard server]
  C --> F[GTK WebKit window]
  E --> G[Update check]
  G --> H[Download and verify AppImage]
  H --> I[Replace AppImage]
  I --> J[Restart from APPIMAGE path]

_{Reviews (1) · Last reviewed commit: "Merge remote-tracking branch 'origin/mai..."}

greptile-apps · 2026-09-28T19:40:25Z

+        let _ = std::fs::remove_file(&path);
+        match UnixListener::bind(&path) {


Concurrent launches lose socket ownership

If two AppImages launch together after a cold start or update restart, both can fail the initial socket connection. One can bind the socket, then the other can remove its pathname and bind a new socket. Both apps keep running, and later launches can no longer focus the first window. The single-instance claim needs to prevent another launch from removing a newly bound socket.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/commands/app.rs Line: 380-381 Comment: **Concurrent launches lose socket ownership** If two AppImages launch together after a cold start or update restart, both can fail the initial socket connection. One can bind the socket, then the other can remove its pathname and bind a new socket. Both apps keep running, and later launches can no longer focus the first window. The single-instance claim needs to prevent another launch from removing a newly bound socket. --- For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

greptile-apps · 2026-09-28T19:40:25Z

+        let dir = std::env::var_os("XDG_RUNTIME_DIR")
+            .map(PathBuf::from)
+            .unwrap_or_else(std::env::temp_dir);
+        // SAFETY: getuid has no failure mode.
+        dir.join(format!("openresearch-app-{}.sock", unsafe {
+            libc::getuid()
+        }))


Shared socket can block launches

If XDG_RUNTIME_DIR is unset, the app uses a predictable socket name in the shared temporary directory. Another local user can bind that name first; the app then treats the connection as an existing instance and exits without opening a window. Use a user-owned socket location and verify ownership before accepting the connection.

How this was verified: The fallback uses a predictable pathname in the shared temporary directory, and any successful connection causes the app to exit its launch path.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/commands/app.rs Line: 361-367 Comment: **Shared socket can block launches** If `XDG_RUNTIME_DIR` is unset, the app uses a predictable socket name in the shared temporary directory. Another local user can bind that name first; the app then treats the connection as an existing instance and exits without opening a window. Use a user-owned socket location and verify ownership before accepting the connection. **How this was verified:** The fallback uses a predictable pathname in the shared temporary directory, and any successful connection causes the app to exit its launch path. --- For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

greptile-apps · 2026-09-28T19:40:25Z

+        .map_err(|e| anyhow!("Could not write {}: {}", staged.display(), e))?;
+    std::fs::set_permissions(staged, std::fs::Permissions::from_mode(0o755))
+        .map_err(|e| anyhow!("Could not make {} executable: {}", staged.display(), e))?;
+    std::fs::rename(staged, appimage)


Updates replace symlinks instead

If the AppImage was launched through a symlink, this rename replaces the symlink rather than its target. The updater reports success and the launcher path runs the new version, but the AppImage at the intended installation path remains old. Resolve the target or reject symlinked installs before updating.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/updates/linux_app.rs Line: 175 Comment: **Updates replace symlinks instead** If the AppImage was launched through a symlink, this rename replaces the symlink rather than its target. The updater reports success and the launcher path runs the new version, but the AppImage at the intended installation path remains old. Resolve the target or reject symlinked installs before updating. --- For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

greptile-apps · 2026-09-28T19:40:25Z

+    // Beside the target, so the final move is a same-filesystem rename.
+    let staged = parent.join(format!(
+        ".OpenResearch-update-{}.AppImage",
+        uuid::Uuid::new_v4()
+    ));
+    let installed = install_staged(&staged, &bytes, appimage);
+    if installed.is_err() {
+        let _ = std::fs::remove_file(&staged);


Interrupted updates leave large files

An interrupted background update can leave a full .OpenResearch-update-*.AppImage beside the installation. Each attempt uses a new filename, while cleanup only handles an error returned by the current attempt, so repeated interruptions consume disk space. Sweep leftovers before staging another update, as the macOS updater does.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/updates/linux_app.rs Line: 125-132 Comment: **Interrupted updates leave large files** An interrupted background update can leave a full `.OpenResearch-update-*.AppImage` beside the installation. Each attempt uses a new filename, while cleanup only handles an error returned by the current attempt, so repeated interruptions consume disk space. Sweep leftovers before staging another update, as the macOS updater does. --- For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

greptile-apps · 2026-09-28T19:40:25Z

+    let bytes = super::fetch_release_asset(
+        &manifest.tag,
+        &asset.asset,
+        // The AppImage carries WebKitGTK, so it is a large download.
+        Duration::from_secs(600),
+    )
+    .await?;


Large downloads fill memory

This passes the WebKit-bundled AppImage through fetch_release_asset, which holds the entire download in memory before it is verified and written to disk. That adds substantial peak memory use and may prevent updates on memory-constrained desktops. Stream the download into the staging file while calculating its checksum.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/updates/linux_app.rs Line: 106-112 Comment: **Large downloads fill memory** This passes the WebKit-bundled AppImage through `fetch_release_asset`, which holds the entire download in memory before it is verified and written to disk. That adds substantial peak memory use and may prevent updates on memory-constrained desktops. Stream the download into the staging file while calculating its checksum. --- For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

# Conflicts: # ui/dist/assets/PdfPreview-BSSxQbi_.js # ui/dist/assets/PdfPreview-BqsPVk8K.js # ui/dist/assets/PdfPreview-CyjErspD.js # ui/dist/assets/index-5RWi1g1b.js # ui/dist/assets/index-WDCgqWTd.js # ui/dist/assets/index-ZrkI6iDM.js # ui/dist/index.html

myles332 and others added 17 commits September 24, 2026 16:21

Run the AppImage detection test only on Unix

47b6271

Its mount paths aren't absolute on Windows, which has no AppImage anyway. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Import the AppImage test's helper inside the Unix-only test

967c598

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/main' into HEAD

0820aca

# Conflicts: # Cargo.lock # ui/dist/assets/index-DLDRL7rV.js # ui/dist/assets/index-UAhw--Xc.js # ui/dist/assets/index-yT9oNk64.js # ui/dist/index.html

Merge remote-tracking branch 'origin/myles/desktop-app' into HEAD

87561b5

Merge remote-tracking branch 'origin/myles/desktop-app-windows' into …

9093d5a

…myles/desktop-app-linux # Conflicts: # ui/dist/assets/index-DLDRL7rV.js # ui/dist/assets/index-Df-zvt4S.js # ui/dist/assets/index-ZrkI6iDM.js # ui/dist/index.html

Merge remote-tracking branch 'origin/main' into HEAD

a89431e

# Conflicts: # Cargo.lock # Cargo.toml # src/commands/app.rs # src/updates.rs

myles332 changed the title ~~Add the Linux desktop app as a self-updating AppImage~~ OR-326 Add the Linux desktop app as a self-updating AppImage Sep 28, 2026

myles332 and others added 2 commits September 28, 2026 11:55

myles332 changed the base branch from myles/desktop-app-windows to main September 28, 2026 19:25

myles332 added 2 commits September 28, 2026 12:28

Merge remote-tracking branch 'origin/myles/desktop-app-windows' into …

0fbc7d4

…myles/desktop-app-linux # Conflicts: # src/commands/app.rs

Merge remote-tracking branch 'origin/main' into myles/desktop-app-linux

a5d03c7

# Conflicts: # Cargo.toml # build.rs # src/commands/app.rs # src/commands/up.rs # src/main.rs # src/telemetry.rs # src/updates.rs # windows/launcher/src/main.rs

myles332 marked this pull request as ready for review September 28, 2026 19:32

myles332 requested a review from sox8502 as a code owner September 28, 2026 19:32

greptile-apps Bot reviewed Sep 28, 2026

View reviewed changes

myles332 merged commit c95be22 into main Sep 28, 2026
15 checks passed

myles332 mentioned this pull request Sep 28, 2026

Make the Linux app's single-instance claim race-free and private #455

Merged

5 tasks

myles332 deleted the myles/desktop-app-linux branch September 28, 2026 21:04

myles332 mentioned this pull request Sep 28, 2026

chore: bump version to 0.2.12 #459

Merged

4 tasks

Navigation Menu

OR-326 Add the Linux desktop app as a self-updating AppImage - #445

OR-326 Add the Linux desktop app as a self-updating AppImage#445
myles332 merged 22 commits into
mainfrom
myles/desktop-app-linux

myles332 commented Sep 25, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Sep 28, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot Sep 28, 2026

Uh oh!

greptile-apps Bot Sep 28, 2026

Uh oh!

greptile-apps Bot Sep 28, 2026

Uh oh!

greptile-apps Bot Sep 28, 2026

Uh oh!

greptile-apps Bot Sep 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

		let _ = std::fs::remove_file(&path);
		match UnixListener::bind(&path) {

Conversation

myles332 commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes

Known gaps

Test plan

Uh oh!

greptile-apps Bot commented Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Confidence Score: 2/5

Findings

Summary

Uh oh!

greptile-apps Bot Sep 28, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 28, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 28, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 28, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 28, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

myles332 commented Sep 25, 2026 •

edited

Loading

greptile-apps Bot commented Sep 28, 2026 •

edited

Loading