AppImage sets PYTHONHOME/PYTHONPATH to non-existent paths, breaking python3 in every process Berd spawns

[Fista420]

Before filing

• I searched open and closed issues for duplicates.
• I reproduced this on the latest release.
• This is one bug, not several bundled together.

Closest existing issue

#195 (#195 is the same packaging hole: linuxdeploy's AppRun.wrapped force-setting env vars to $APPDIR paths that don't exist in the bundle. #195 is GST_PLUGIN_SYSTEM_PATH* (WebKit audio sink aborts); this is PYTHONHOME/PYTHONPATH (Python interpreter aborts). The fix requested in #195 — porting Buzz's desktop/scripts/fix-appimage.sh shim — should cover this too, if the shim handles the Python vars alongside the GStreamer ones.)

What's broken

The Linux AppImage exports PYTHONHOME and PYTHONPATH pointing inside its own
mount point, but bundles no Python runtime. Every python3 process Berd spawns
therefore aborts at interpreter startup with "Failed to import encodings module",
so Python is unusable in agent tool calls and in the in-app terminal.

Steps to reproduce

1. Launch Berd 0.6.4 from the AppImage, freshly started.
2. Start a new chat session. No prior history is needed — a fresh session
   reproduces it.
3. Ask the agent to run a Python command, e.g.:
   python3 -c "print('hello')"
   (I used the goose harness with kimi-k3 via a custom OpenAI-compatible
   provider. The bug is model- and provider-independent: it is environment
   inheritance, so any harness, model, or tool that spawns python3 reproduces
   it. It also reproduces with no model involved at all — open the terminal
   in the session right rail and run the same command by hand.)
4. Observe the interpreter abort before any user code runs.

Optional — confirms it is inherited rather than session-specific:

for p in $(pgrep -f berd); do
  tr '\0' '\n' < /proc/$p/environ | grep -E '^PYTHON(HOME|PATH)='
done

Setup notes: Arch-family distro (CachyOS) where /usr/bin/python3 is the system
interpreter and works normally outside Berd; fish as the login shell.

What you expected to happen

python3 inside a Berd session behaves exactly as it does in my own terminal,
using the system interpreter and its standard library.

What actually happened

The interpreter aborts at startup:

$ python3 -c "print('hello')"
Fatal Python error: Failed to import encodings module
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00007fb0a38ec480 (most recent call first):
<no Python frame>

Deterministic: 5/5 runs failed.

There is a second, independently reproducible symptom from the same cause.
Any bash login shell launched under Berd's environment prints a Python fatal
error on stderr, because /etc/profile.d/vapoursynth.sh runs a Python script
(vapoursynth get-vsscript) during shell startup:

$ env -i HOME="$HOME" PATH="$PATH" \
    PYTHONHOME=/tmp/.mount_berd.XXXXXX/usr/ \
    PYTHONPATH=/tmp/.mount_berd.XXXXXX/usr/share/pyshared/: \
    /bin/bash -l -c 'echo OK'
OK
Fatal Python error: Failed to import encodings module
...
Current thread 0x00007fa523cecbc0 [vapoursynth] (most recent call first):

Remove the two variables and the same command produces no stderr at all.
This pollutes the output of every login shell Berd spawns, which is a
plausible cause of scripts and tooling that parse shell output misbehaving.

Workaround: prefix Python invocations with
env -u PYTHONHOME -u PYTHONPATH python3 ...

How often does it happen?

Every time — reliably reproducible

Berd version

0.6.4

Operating system

Linux

Model and provider

Deepseek v4.1 flash, kimi-k3

Relevant log output

Two honest observations here, since neither is a smoking gun.

1. The Python failure itself is silent. I grepped berd.log for "python",
   "encodings" and "PYTHONHOME" across all 2,552 lines and got zero matches.
   Berd does not appear to log the stderr of the subprocess that fails, which
   is a large part of why this is hard to diagnose from the app side. Worth
   noting as a diagnostic gap in its own right.

2. The only environment-related warnings in the logNetwork error: Stream decode error: error decoding response body

Please resend your message to try again.

Screenshots, recordings, or other context

Installed appimage on cachyos arch linux using gear lever.

How often does it happen?

Always — 100%, deterministic. 5/5 direct invocations failed, and it reproduced
on every launch. The error text varies between launches because the AppImage
mount point is a fresh tmpfs each time (/tmp/.mount_berd.), but the
failure itself is constant.

Operating system

Linux — CachyOS (Arch-family), kernel 7.2.2-1-cachyos, x86_64
Install format: AppImage (~/AppImages/berd.appimage, 212,814,328 bytes)
Login shell: fish
System Python: /usr/bin/python3 → 3.14.6 (works normally outside Berd)

Model and provider

goose harness; model kimi-k3 via a custom OpenAI-compatible provider.
n/a in the sense that the bug does not involve the model — it is environment
inheritance from the app process. It reproduces with the model removed from
the loop entirely (terminal in the session right rail).