#544
Issues/Dimillian/CodexMonitor/#544

AppImage freezes when opening any workspace on Linux, while local --no-bundle build works correctly

Opensh4869221bopened 7mo ago

Description

Codex Monitor AppImage launches successfully, but freezes as soon as I open a project/workspace.

This reproduces even with:

  • a brand new empty git repository
  • a completely fresh config/data directory
  • X11 backend forced
  • WebKit DMA-BUF renderer disabled

However, a local source build works correctly on the same machine and in the same environment.

Environment

  • OS: CachyOS / Linux
  • WM/Compositor: niri
  • GPU: NVIDIA GeForce RTX 4070
  • Install type affected: AppImage

Reproduction

  1. Launch Codex Monitor AppImage
  2. Add/open any workspace
  3. UI freezes immediately after opening the project

Also reproduces with a fresh state: mkdir -p /tmp/cm-test-config /tmp/cm-test-data env XDG_CONFIG_HOME=/tmp/cm-test-config
XDG_DATA_HOME=/tmp/cm-test-data
./Codex.Monitor_*.AppImage

Also reproduces with: env GDK_BACKEND=x11 WEBKIT_DISABLE_DMABUF_RENDERER=1 ./Codex.Monitor_*.AppImage

Also reproduces with a brand new repo: mkdir -p /tmp/cm-empty-test cd /tmp/cm-empty-test git init

codex app-server itself does not immediately crash when run manually in that repo.

What works

A local build from source works correctly on the same system:

export RUSTUP_TOOLCHAIN=stable export LIBSSH2_SYS_USE_PKG_CONFIG=1 cd CodexMonitor npm ci npm run tauri -- build --no-bundle

The binary produced this way does not freeze when opening projects/workspaces.

Expected behavior

Opening a workspace should not freeze the UI.

Notes

This appears to be specific to the AppImage build or its bundled runtime/environment, rather than a general Codex Monitor logic failure, because:

  • it reproduces with a completely fresh config/data directory
  • it reproduces with an empty repo
  • it still reproduces with X11 forced and DMA-BUF disabled
  • a local --no-bundle build works correctly on the same machine

Activity

3
darkedx7mo ago

same question.

darkedx7mo ago

same question.

sh4869221b7mo ago

I did a deeper local investigation and the evidence now points away from workspace-specific logic and toward the Linux AppImage runtime itself.

Findings:

  • I extracted the released AppImage (Codex.Monitor_0.7.66_amd64.AppImage) and ran the extracted AppRun directly.
  • The extracted AppImage fails even with a completely empty state, before any workspace interaction is required.
  • The failure is:

Could not create surfaceless EGL display: EGL_BAD_ALLOC. Aborting...

What I checked:

  1. Empty state

    • I created a fresh app data dir with an empty workspaces.json.
    • Running the extracted AppImage still failed with the same EGL_BAD_ALLOC error.

  2. Preloaded workspace state

    • I created a fresh app data dir with one workspace already present in workspaces.json.
    • Running the extracted AppImage still failed with the same EGL_BAD_ALLOC error.

  3. Local non-bundled binary

    • Running the local source-built debug binary in the same environment did not produce the EGL error.
    • That matches the original report that --no-bundle works.

Why this matters:

  • The AppImage bundles its own GTK/WebKit stack, including libwebkit2gtk-4.1.so.0.
  • Its launcher also forces GTK/X11-related runtime environment through the linuxdeploy GTK hook.
  • Since the crash reproduces with an empty state, this does not currently look like a workspace restore bug or a codex app-server startup bug.
  • It looks much more like an AppImage-bundled WebKitGTK/EGL incompatibility on this Linux/NVIDIA/Wayland-family setup.

I also tried a few runtime toggles while reproducing from the extracted AppImage:

  • WEBKIT_DISABLE_COMPOSITING_MODE=1
  • LIBGL_ALWAYS_SOFTWARE=1
  • clearing WAYLAND_DISPLAY / forcing XDG_SESSION_TYPE=x11

Those did not change the extracted-AppImage failure here.

Current conclusion:

  • The freeze is most likely caused by the AppImage's bundled WebKitGTK/EGL runtime path, not by workspace open logic itself.
  • Workspace opening likely only makes the problem visible in normal usage.