actions/sindri
actions/sindri
2
0
Fork 0
Code Issues 2 Pull requests Releases 11 Packages 1 Activity Actions

#0 - Fix Electron app launches (Lens, Claude Desktop, ...) in unprivileged Kubernetes pods #11

Merged
GuillaumeHemmen merged 1 commit from 0-fix-electron-app-launches into master 2026-06-11 15:11:50 +00:00
Conversation 0 Commits 1 Files changed 5 +165 -11
GuillaumeHemmen commented 2026-06-11 14:54:48 +00:00
Owner
Copy link

What

Electron apps (Lens, a user-installed Claude Desktop, VS Code, ...) crashed instantly in the coder-xfce-vnc workspace. Two independent root causes, both verified live in a running workspace, both now handled by the image:

  1. The Chromium sandbox cannot work in an unprivileged pod running the RuntimeDefault seccomp profile: unprivileged user namespaces are blocked, and the setuid chrome-sandbox fallback cannot re-gain CAP_SYS_ADMIN (excluded from the bounding set). → ENV ELECTRON_DISABLE_SANDBOX=1 stage-wide.
  2. The default 64 MiB /dev/shm overruns at desktop resolution → renderer crashes (exitCode: 4) and misleading GPU process isn't usable. Goodbye. fatals. → every Lens launch path (PATH, XFCE menu, lens:// URLs) routes through a wrapper adding --disable-dev-shm-usage.

Supporting changes:

  • Lens desktop-entry override is generated at build time from the entry the package installs; assertions fail the build if the package changes shape. The wrapper targets the deb's update-alternatives entry point so upgrades cannot strand it.
  • coder-init-desktop parks (renames to .bak) a stale user-local Lens entry on the PVC that would otherwise shadow the wrapper-routed override forever.
  • Fixed the dead /usr/local/bin/jetbrains-toolbox symlink (Toolbox 2.x keeps the binary under bin/) and aligned its desktop entry with the documented --disable-gpu.
  • Full diagnosis documented in README ("Electron & Chromium-based apps").

Verification

  • Lens launches cleanly via terminal and the XFCE menu path in a live workspace: flags and env present on the process, windows mapped, /dev/shm flat, zero renderer crashes.
  • A minimal generic Electron app reproduces the crash without the fix and opens with only the image env var — so user-installed Electron apps (e.g. Claude Desktop community builds) work too.

Note

Stacked on 8d094d2 (Lens install, branch 0-add-k8s-tooling) because the fix modifies that Dockerfile block. If that branch merges to master first, this PR reduces to the fix commit alone.

🤖 Generated with Claude Code

## What Electron apps (Lens, a user-installed Claude Desktop, VS Code, ...) crashed instantly in the `coder-xfce-vnc` workspace. Two independent root causes, both verified live in a running workspace, both now handled by the image: 1. **The Chromium sandbox cannot work in an unprivileged pod** running the `RuntimeDefault` seccomp profile: unprivileged user namespaces are blocked, and the setuid `chrome-sandbox` fallback cannot re-gain `CAP_SYS_ADMIN` (excluded from the bounding set). → `ENV ELECTRON_DISABLE_SANDBOX=1` stage-wide. 2. **The default 64 MiB `/dev/shm` overruns** at desktop resolution → renderer crashes (`exitCode: 4`) and misleading `GPU process isn't usable. Goodbye.` fatals. → every Lens launch path (PATH, XFCE menu, `lens://` URLs) routes through a wrapper adding `--disable-dev-shm-usage`. Supporting changes: - Lens desktop-entry override is **generated at build time** from the entry the package installs; assertions fail the build if the package changes shape. The wrapper targets the deb's `update-alternatives` entry point so upgrades cannot strand it. - `coder-init-desktop` parks (renames to `.bak`) a stale user-local Lens entry on the PVC that would otherwise shadow the wrapper-routed override forever. - Fixed the dead `/usr/local/bin/jetbrains-toolbox` symlink (Toolbox 2.x keeps the binary under `bin/`) and aligned its desktop entry with the documented `--disable-gpu`. - Full diagnosis documented in README ("Electron & Chromium-based apps"). ## Verification - Lens launches cleanly via terminal and the XFCE menu path in a live workspace: flags and env present on the process, windows mapped, `/dev/shm` flat, zero renderer crashes. - A minimal generic Electron app reproduces the crash without the fix and opens with only the image env var — so user-installed Electron apps (e.g. Claude Desktop community builds) work too. ## Note Stacked on `8d094d2` (Lens install, branch `0-add-k8s-tooling`) because the fix modifies that Dockerfile block. If that branch merges to master first, this PR reduces to the fix commit alone. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
GuillaumeHemmen force-pushed 0-fix-electron-app-launches from 124c3f8838
All checks were successful
/ docker-dev-ci (push) Successful in 3m19s
Details
/ docker-dev-coder (push) Successful in 3m51s
Details
/ docker-dev-coder-xfce-vnc (push) Successful in 8m5s
Details
to 337cf8b93c
All checks were successful
/ docker-dev-ci (push) Successful in 3m56s
Details
/ docker-dev-coder (push) Successful in 4m21s
Details
/ docker-dev-coder-xfce-vnc (push) Successful in 8m24s
Details
2026-06-11 15:07:21 +00:00 Compare
GuillaumeHemmen scheduled this pull request to auto merge when all checks succeed 2026-06-11 15:10:12 +00:00
GuillaumeHemmen deleted branch 0-fix-electron-app-launches 2026-06-11 15:11:50 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
actions/sindri!11
No description provided.