Linux: AppImage leaks bundled LD_LIBRARY_PATH to spawned git (bundled git + libnghttp2 variant), blocking session creation — regression of #644

[sjwilczynski]

Short summary

The Linux AppImage still leaks its bundled LD_LIBRARY_PATH to spawned git, breaking HTTPS and blocking session creation — appears to be a regression / incomplete fix of #644 (closed COMPLETED 2026-06-05). This time it's the bundled git's git-remote-https loading the AppImage's old bundled libnghttp2.so.14 instead of the system one, on Ubuntu 24.04.

Affected version or release

• GitHub Copilot app: 1.0.5 (from the in‑app About/Settings)
• AppImage build date: 2026-06-23 (GitHub-Copilot-linux-x64.AppImage)
• Bundled components: desktop runtime copilot-desktop-gh-2.95.0, bundled git github-copilot-git-2.53.0-3 (git 2.53.0), bundled Copilot CLI 1.0.64-1

Installation context

AppImage (GitHub-Copilot-linux-x64.AppImage, linux-x64), FUSE-mounted at /tmp/.mount_GitHub<random>. The app uses its bundled git (logs: using bundled git).

What happened?

Creating a session fails during workspace initialization (git fetch over HTTPS) with:

git-remote-https: symbol lookup error: /lib/x86_64-linux-gnu/libcurl-gnutls.so.4:
  undefined symbol: nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation
fatal: remote helper 'https' aborted session

This reproduces reliably (blocked session creation on two separate occasions).

Relationship to #644: #644 reported the same root cause — the AppImage exports its extracted/mounted lib dir via LD_LIBRARY_PATH to spawned git, so git loads the AppImage's outdated bundled libs instead of system ones — and was closed as COMPLETED. It still happens on the current build, with a different library pair:

• Bug: AppImage injects bundled libs into system git's environment, breaking on modern distros #644: system git loading bundled libssl/libpcre2 (Arch, OpenSSL version mismatch).
• This report: the bundled git's git-remote-https loading the bundled libnghttp2.so.14 (Ubuntu 24.04), which is older than the system one and is missing a symbol the system libcurl-gnutls.so.4 requires.

Root cause (verified):

1. The AppImage runtime exports to every child process an LD_LIBRARY_PATH pointing at its mount, e.g. /tmp/.mount_GitHubXXXX/usr/lib/:/tmp/.mount_GitHubXXXX/usr/lib/x86_64-linux-gnu/:...
2. The bundle ships an old nghttp2: /tmp/.mount_GitHubXXXX/usr/lib/libnghttp2.so.14 is missing nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation (nm -D → 0 matches). System /lib/x86_64-linux-gnu/libnghttp2.so.14 → libnghttp2.so.14.26.0 has it (nm -D → 1 match).
3. The bundled git-remote-https links system libcurl-gnutls.so.4, whose NEEDED list includes libnghttp2.so.14. With the AppImage LD_LIBRARY_PATH taking precedence, the loader binds the old bundled nghttp2, the required symbol is absent, and the helper dies on symbol lookup.

Why it's clearly the spawn environment, not the host:

• Running the same bundled git from a clean shell (no AppImage LD_LIBRARY_PATH) works: git ls-remote https://github.com/git/git HEAD returns the SHA, exit 0.
• Reproducing with only that LD_LIBRARY_PATH set makes the bundled git-remote-https symbol-error (exit 127); unsetting it fixes it (exit 0).
• The system nghttp2 is current/healthy; the only "bad" nghttp2 on the machine is the one inside the AppImage bundle.

Steps to reproduce

1. Run the GitHub Copilot AppImage (app 1.0.5) on Ubuntu 24.04 (system libcurl is the gnutls variant, which pulls libnghttp2.so.14).
2. Create a session for any GitHub repo (triggers a workspace git fetch over HTTPS).
3. Workspace init fails with the symbol lookup error above.

Minimal repro of the mechanism, using the app's own bundled git:

BGIT=~/.cache/github-copilot-git-<ver>/bin/git
APPLIB=/tmp/.mount_GitHub<random>/usr/lib

# Fails (mimics how the app spawns git):
LD_LIBRARY_PATH="$APPLIB" "$BGIT" ls-remote https://github.com/git/git HEAD
# -> symbol lookup error ... nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation

# Works (clean env):
"$BGIT" ls-remote https://github.com/git/git HEAD

Expected behavior

The app should spawn git to fetch over HTTPS and initialize the workspace regardless of host libcurl/nghttp2 versions. System binaries (and the bundled git linking system libs) spawned by the app should resolve system libraries, not the AppImage's bundled ones.

Suggested fixes (any one resolves it; same direction as #644):

1. Don't leak the bundle's LD_LIBRARY_PATH to spawned subprocesses — sanitize/restore LD_LIBRARY_PATH (and LD_PRELOAD) to the pre‑AppImage value before spawning git (or launch git via env -i / a clean env). This is the cleanest fix and covers both the Bug: AppImage injects bundled libs into system git's environment, breaking on modern distros #644 and this nghttp2 variant.
2. Wrap the bundled git so its remote helpers run with a clean LD_LIBRARY_PATH.
3. Ship a fully self-contained git in the AppImage (so it never mixes system libcurl-gnutls with a bundled, older nghttp2), or ensure the bundled nghttp2 is recent enough for the symbols its linked libcurl needs.

Additional context

• OS: Ubuntu 24.04.4 LTS, x86_64
• Severity: high — sessions cannot be created at all; the only surfaced symptom is an opaque libcurl symbol error.
• Affects any distro where system libcurl-gnutls.so.4 requires a newer nghttp2 symbol than the AppImage's bundled libnghttp2.so.14 provides.
• Local workaround in use (reversible): wrapped the bundled git-remote-http helper with a shim that runs unset LD_LIBRARY_PATH; unset LD_PRELOAD; exec git-remote-http.real "$@". Verified: the wrapped helper returns capabilities cleanly under the bad env (exit 0); the raw binary symbol-errors (exit 127). Per-machine stopgap, not a product fix.
• Originally (mis)filed on github/copilot-cli as #3925; closing that in favor of this one, since the desktop app is the right component.