Skip to content

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

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

Description

@sh4869221b
sh4869221b
opened on Mar 7, 2026

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

  1. darkedx commented on Mar 11, 2026

    @darkedx
    darkedx
    on Mar 11, 2026

    same question.

  2. sh4869221b commented on Mar 23, 2026

    @sh4869221b
    sh4869221b
    on Mar 23, 2026
    Author

    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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions