Linux: AppImage leaks bundled LD_LIBRARY_PATH to spawned git, breaking HTTPS (libnghttp2 symbol lookup) and blocking session creation

[sjwilczynski]

Describe the bug

On Linux, the GitHub Copilot Desktop AppImage exports its bundled-library LD_LIBRARY_PATH into the environment of the child processes it spawns. When the app spawns its bundled git to initialize a session workspace (git fetch over HTTPS), git's git-remote-https helper loads the AppImage's older bundled libnghttp2.so.14 instead of the system one. That older nghttp2 is missing a symbol the system libcurl-gnutls.so.4 requires, so the helper aborts and session workspace initialization fails — no session can be created:

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 (it blocked session creation on two separate occasions).

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/:/tmp/.mount_GitHubXXXX/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). The system /lib/x86_64-linux-gnu/libnghttp2.so.14 → libnghttp2.so.14.26.0 has it (nm -D → 1 match).
3. The bundled git's 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 user's system:

• Running the same bundled git from a normal 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.

Affected version

• Copilot CLI: 1.0.64-1
• Copilot Desktop (AppImage): 2.95.0 (GitHub-Copilot-linux-x64.AppImage; active runtime cache copilot-desktop-gh-2.95.0)
• Bundled git: github-copilot-git-2.53.0-3 (git 2.53.0)

Steps to reproduce the behavior

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

Minimal CLI repro of the underlying 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 be able to spawn its bundled git to fetch over HTTPS and initialize a session workspace, regardless of the host's libcurl/nghttp2 versions. System binaries spawned by the app should resolve system libraries, not the AppImage's bundled ones.

Suggested fixes (any one resolves it):

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 when spawning git and other system tools. (Standard AppImage guidance for invoking external system tools; cleanest fix.)
2. Wrap the bundled git so its remote helpers run with a clean LD_LIBRARY_PATH (strip the AppImage bundle dirs before exec).
3. Bundle git's HTTP stack consistently (ship a git-remote-https that doesn't mix 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

• Operating system: Ubuntu 24.04.4 LTS
• CPU architecture: x86_64
• Severity: high on affected Linux setups — 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 (e.g. Ubuntu 24.04).

Local workaround in use (reversible): wrapped the bundled git-remote-http helper with a shell 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). This is a per-machine stopgap, not a product fix.

[sjwilczynski]

Closing — filed against the wrong component. This is a GitHub Copilot desktop app (github/app) bug, not a Copilot CLI bug. Moved to github/app#1394 (framed as a regression of github/app#644). Apologies for the noise here.