Repository navigation
[Bug] AppImage fails to start correctly on Fedora 44 unless --no-sandbox is used #32
Description
Description
Termpolis 1.49.4 AppImage does not start correctly on Fedora 44 when launched normally.
The application works correctly when the Chromium/Electron sandbox is completely disabled using --no-sandbox.
The issue appears to be related to Electron/Chromium sandbox initialization. Chromium reports a /dev/shm permissions problem, although /dev/shm permissions and write access have been verified and are correct.
Steps to Reproduce
- Download
Termpolis-1.49.4.AppImage. - Make the AppImage executable.
- Start it normally:
LANG=C ./Termpolis-1.49.4.AppImage
- Termpolis starts its backend/MCP components, but the Electron/Chromium frontend fails to start correctly.
- Start it again with:
LANG=C ./Termpolis-1.49.4.AppImage --no-sandbox
- Termpolis starts and works correctly.
Expected Behavior
Termpolis should start and work normally on Fedora 44 without requiring the Chromium/Electron sandbox to be disabled.
Actual Behavior
Without --no-sandbox, Chromium/Electron reports:
ERROR:platform_shared_memory_region_posix.cc(214)]
Creating shared memory in /dev/shm/.org.chromium.Chromium.* failed: No such process (3)
ERROR:platform_shared_memory_region_posix.cc(217)]
Unable to access(W_OK|X_OK) /dev/shm: No such process (3)
FATAL:platform_shared_memory_region_posix.cc(219)]
This is frequently caused by incorrect permissions on /dev/shm.
Try 'sudo chmod 1777 /dev/shm' to fix.
However, /dev/shm is configured correctly:
$ ls -ld /dev/shm
drwxrwxrwt. 2 root root ... /dev/shm
$ findmnt /dev/shm
TARGET SOURCE FSTYPE OPTIONS
/dev/shm tmpfs tmpfs rw,nosuid,nodev,seclabel,inode64,usrquota
$ stat -c '%a %U %G %n' /dev/shm
1777 root root /dev/shm
$ touch /dev/shm/test-$USER && rm /dev/shm/test-$USER && echo OK
OK
SELinux does not appear to be blocking anything:
$ getenforce
Permissive
$ sudo ausearch -m AVC,USER_AVC -ts recent
<no matches>
User namespaces are also available:
$ sysctl user.max_user_namespaces
user.max_user_namespaces = 255555
$ unshare -Ur true
$ echo $?
0
Tested Chromium/Electron options:
--disable-gpu-sandbox
Result: only a black window.
--disable-dev-shm-usage
Result: does not resolve the problem.
--no-sandbox
Result: Termpolis starts and works correctly.
Currently, --no-sandbox is the only workaround I have found.
Environment
- OS: Fedora Linux 44, Wayland
- Termpolis version: 1.49.4
- Package: x86_64 AppImage
- Shell: Bash
- SELinux: Permissive
- Display server: Wayland
Screenshots
Not applicable. The relevant Chromium/Electron error output is included above.
Additional Context
The Termpolis backend appears to start successfully before the Chromium/Electron failure. For example:
[workflow] orchestrator IPC registered (0 trigger(s) armed)
[agents] claude: update MCP server
[agents] codex: update MCP server
[agents] gemini: update MCP server
Termpolis MCP server listening on http://127.0.0.1:9315
[termpolis][memory] store is OFF the main thread
[termpolis][memory] brain is OFF the main thread (mode=host)
Since the application works correctly with --no-sandbox, while /dev/shm, SELinux, and unprivileged user namespaces have been verified, this looks like an Electron/Chromium sandbox compatibility issue rather than an actual /dev/shm permissions problem.
I would be happy to provide additional logs or test a debug build/fix on Fedora 44.
Activity
fix(linux): stop turning the sandbox off from code, which killed the …
v1.51.5: Linux AppImage starts with the sandbox on; dropped files typ…
codedev-david commentedon Oct 13, 2026
Thanks for the detailed report. The checks you ran (
/dev/shm, SELinux, user namespaces) ruled out the usual suspects and pointed at the real cause, which was in Termpolis. It's fixed in v1.51.5.What was wrong: on Linux, Termpolis turned Chromium's sandbox off from inside the app at startup (
app.commandLine.appendSwitch('no-sandbox')). That runs too late. By then Chromium has already started its zygote inside the user-namespace sandbox, because your kernel allows one. Each renderer was then told it was unsandboxed while it was still inside that sandbox. It failed to create shared memory, and the window died with the/dev/shmFATAL you saw. Passing--no-sandboxon the command line worked because Chromium sees it before the zygote starts./dev/shmitself was never the problem. It also wasn't Fedora-specific: the 1.51.4 AppImage fails the same way in Fedora 44 and Ubuntu 22.04 containers.v1.51.5 removes that switch. I ran the released
Termpolis-1.51.5.AppImagein a Fedora 44 container, launched normally with no flags. The window opens and a terminal runs commands. The renderer runs inside Chromium's sandbox, in its own nested PID namespace. Where user namespaces are blocked (Ubuntu 24.04's default, for example), the AppImage's launcher still adds--no-sandboxby itself, as before. CI now also starts the app on Linux with the sandbox on, so this can't come back unnoticed.I tested in a container, not on a real Fedora 44 Wayland desktop, so a quick check would help. Could you try
Termpolis-1.51.5.AppImagewithout any flags? If it still fails, reopen this issue with the output and I'll pick it up.blondak commentedon Oct 13, 2026
Thanks for the fix! I've tested it on Fedora 44 and can confirm that everything is now working correctly.
Termpolis starts and runs normally without the
--no-sandboxworkaround.Thanks for the quick resolution!