sudo and bwrap-based sandboxes (e.g. Codex CLI) break inside a shell spawned by the AppImage - FUSE mount runs in a private user namespace

[codemedic]

Summary

Any shell (or child process) spawned by the AppImage inherits a private, unprivileged user namespace created during the FUSE/DwarFS self-mount. Tools that check real uid/capability metadata against on-disk ownership - sudo, and sandboxes built on bubblewrap (e.g. Codex CLI) - fail inside that shell, because root (uid 0) isn't mapped in the namespace.

Reproduction

$ ~/Applications/Ghostty-<version>-x86_64.AppImage
# in the resulting shell:
$ sudo apt update
sudo: /etc/sudo.conf is owned by uid 65534, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

Evidence

• cat /proc/self/uid_map in the shell: 1000 1000 1 - only uid 1000 is mapped; uid 0 has no mapping, so root-owned files appear as uid 65534 (kernel.overflowuid).
• Compare to /proc/1/uid_map (init, not namespaced): full range mapped.
• readlink /proc/<pid>/ns/user is identical across the dwarfs mount process, the ghostty binary, and the login shell - confirming they share one namespace.
• strace -f -e trace=clone,clone3,unshare,setns on the raw AppImage shows the runtime attempting a pidfd-based setns() (namespace reuse across launches); the fully-extracted binary (--appimage-extract then run AppRun directly) makes zero such calls.
• /proc/self/status in the shell shows CapEff: 00000000ffffffff - full capabilities despite not being setuid/root, which is what trips bwrap's own sanity check (bwrap: Unexpected capabilities but not setuid, old file caps config?), breaking Codex CLI's sandbox the same way.

Workaround confirmed working

Embedding APPIMAGE_EXTRACT_AND_RUN=1 via --appimage-addenvs avoids the FUSE mount (and thus the namespace) entirely - verified via strace: zero clone/unshare/setns calls, sudo and bwrap both work normally afterward.

Question for you

Given #158 was actually fixed upstream in Anylinux-AppImages rather than here, is this the same situation - i.e. is the unshare/reuse behavior coming from uruntime/quick-sharun rather than anything ghostty-appimage-specific? If so, is baking APPIMAGE_EXTRACT_AND_RUN=1 into the build (or fixing the reuse logic to not require a private namespace) something you'd want done here, upstream, or not at all? Happy to send a PR to bin/bundle-appimage.sh if that's the right place - wanted your read first given the shared-tooling precedent.

---

Note: written with AI assistance (Claude Code) during a debugging session.

[Samueru-sama]

@codemedic I'm unable to reproduce this issue.

---

Do you have FUSE in your system? Because the appimage will use unshare if it is unable to mount with FUSE, which will result in those issues when trying to run suid binaries.

[Samueru-sama]

Also note that running the appimage with strace automatically makes it use unshare instead btw.

[codemedic]

Sorry about that - should have caught that strace changes the runtime's own mount behavior before presenting it as evidence. That one's on me!

You're right to push on that, and it exposed a flaw in my report. Re-tested without strace on the same machine: a clean launch mounts via FUSE normally (uid_map shows the standard initial namespace, no unshare). So the strace-based comparison I posted (extracted path = zero clone/unshare vs. raw path = pidfd/setns attempt) was measuring strace itself forcing the fallback, not default behavior - retracting that part.

FUSE is present and generally working here: fusermount3 is setuid-root, /dev/fuse is world-rw, and manual launches mount fine every time I've tried since.

The original failure (uid 65534 sudo error, uid_map genuinely 1000 1000 1, no strace involved) happened specifically in a terminal launched by KDE session-restore at boot. Journalctl shows a bunch of other apps (Dropbox, Akonadi, a few Flatpaks, KDE Connect, etc.) starting around the same second, so there may be some contention at that point, but I haven't confirmed that's actually what tips FUSE over - just noting it as a possible factor. I haven't been able to force-reproduce it on demand outside a real cold boot either, so no clean repro script yet.

If it'd help, I can try capturing stderr / ENABLE_FUSE_DEBUG=1 output from the actual session-restore launch on the next reboot to catch the real FUSE failure reason in the moment, rather than reasoning it back from a strace-contaminated repro.

[codemedic]

One correction to the original report: reproduction isn't "every launch" as the issue body implies. I've hit this several times, most noticeably when running sudo, but I don't use sudo every session, so I can't rule out it happening more often than I've noticed and just going unseen. Treat this as suspected-intermittent rather than a reliable on-demand repro - that's also why I haven't been able to force it for a clean debug capture outside of an actual reboot.

[codemedic]

Got a real capture this time - no strace involved. Set ENABLE_FUSE_DEBUG=1 on the .desktop Exec line that KDE's session-restore actually invokes, then rebooted. It reproduced, and this time I have the runtime's own explanation straight from the log:

The mount process ended unexpectedly! PID: 3586
Trying to unshare...

To answer your original question directly: yes, FUSE is present and working on this host. Kernel fuse module loads at boot (fuse: init (API version 7.39)), the FUSE control filesystem mounts fine, fusermount3 is setuid-root, /dev/fuse is world-rw, and manual launches mount via FUSE successfully every time I've tested. So this isn't "no FUSE available" - it's that one specific mount attempt, at boot, intermittently fails.

This confirms exactly what you said: the first-attempt FUSE mount helper (PID 3586) died, and the built-in fallback caught that and retried via unshare, landing the whole process tree (mount, ghostty binary, shell) in a private user namespace - confirmed again via uid_map/ns/user, matching across the tree, distinct from the initial namespace.

What I don't have: why PID 3586 died. No coredump, no signal, nothing else in the journal tagged with that PID - just the parent logging that it ended unexpectedly. So the underlying trigger (resource contention at boot, a transient /dev/fuse timing issue, something else) is still an open question. Happy to dig further if there's a specific thing you'd want checked (cgroup limits, /dev/fuse access timing, anything else) - let me know what would be useful data to gather on the next occurrence.

[Samueru-sama]

@codemedic do you have this problem with the latest nightly release?

[codemedic]

Quick clarification on why APPIMAGE_EXTRACT_AND_RUN=1 is needed, and what I'm actually asking for help with.

Why: the real bug is the FUSE mount helper dying at boot (confirmed in the runtime log: The mount process ended unexpectedly! PID: 3586 -> Trying to unshare...). The unshare fallback is what puts everything in a private namespace and breaks sudo/bwrap. APPIMAGE_EXTRACT_AND_RUN=1 just avoids FUSE entirely - it doesn't explain or fix why the mount helper dies.

The ask: why does that mount process die at boot? FUSE itself checks out fine here - kernel module loads, fusermount3 is setuid-root, /dev/fuse is world-rw, manual launches mount cleanly every time. Looks timing/environment-related, not a missing dependency, but I haven't dug into uruntime's own mount code to chase it further - if you (or anyone familiar with that codebase) know what could cause the mount helper to die under load, that would save a lot of guessing.

What I built around the workaround (for anyone else hitting this via a desktop-integration tool that regenerates .desktop files)

1. Baked into the AppImage file itself, so it survives regardless of launcher config:

./Ghostty.AppImage --appimage-addenvs 'APPIMAGE_EXTRACT_AND_RUN=1'

2. Auto-reapplied if the file gets replaced by an update, via a systemd --user path watcher (idempotent - no-op if already set):

# ~/.config/systemd/user/ghostty-fixup.path
[Path]
PathChanged=%h/Applications/Ghostty.AppImage
Unit=ghostty-fixup.service

[Install]
WantedBy=default.target

#!/usr/bin/env bash
# ~/bin/ghostty-fixup.sh, run by ghostty-fixup.service
set -euo pipefail
appimage="$HOME/Applications/Ghostty.AppImage"
[[ -x "$appimage" ]] || exit 0
if ! "$appimage" --appimage-envs 2>/dev/null | grep -qx 'APPIMAGE_EXTRACT_AND_RUN=1'; then
    "$appimage" --appimage-addenvs 'APPIMAGE_EXTRACT_AND_RUN=1'
fi

3. Extract-and-run has its own milder failure mode: an interrupted extraction under boot load leaves AppRun missing, window never appears. Fixed by moving "launch at login" to a plain autostart entry instead of KDE session-restore, plus a logout-time cleanup:

# ~/.config/autostart/ghostty-autostart.desktop
[Desktop Entry]
Type=Application
Name=Ghostty (autostart)
Exec=/path/to/your/ghostty-wrapper-script
NoDisplay=true

# ~/.config/plasma-workspace/shutdown/ghostty-cleanup.sh
for dir in "${TMPDIR:-/tmp}"/appimage_extracted_ghost*; do
    [[ -d "$dir" ]] && rm -rf "$dir"
done

Two clean reboots since. None of this fixes the root cause, just makes both failure modes survivable. Happy to gather more diagnostics on the mount-helper death if useful.

[codemedic]

do you have this problem with the latest nightly release?

Yes, I am using the latest nightly build.

[Samueru-sama]

ping @VHSgunzo

[VHSgunzo]

ping @VHSgunzo

Hi! I can’t see a clear list of steps to reproduce the issue, or any information about the system or versions of everything that was in use when the problem occurred.
For now, it looks like the bug in KDE (which I can’t reproduce on my own system).