SaaS Metrics
GitHub Issue
Ubuntu Desktop support: complete staged implementation and portable foundation
## Goal
Deliver a first-class Ubuntu Desktop build of OpenMausBot without regressing macOS or overstating native capabilities that are not yet proven on Linux.
Proposed initial support target:
- **Ubuntu 24.04 LTS, x86_64**
- **`.deb` as the recommended Ubuntu package**, plus AppImage as the portable option
- GNOME on both **Xorg and Wayland** for the baseline Electron shell
- Chat, local agent CLIs, Composio, Box/cloud computers, and the embedded harness
- Linux dictation and local computer control added only in later, separately validated phases
I am volunteering to coordinate and implement the Ubuntu baseline in one cohesive PR, organized into atomic commits with real Ubuntu test evidence for every platform claim. Later native capabilities remain independently reviewable follow-ups on this roadmap.
## Why this needs an issue first
The React UI and Node harness already run on Linux, but the packaged Electron application is still macOS-oriented:
- `package.json` always compiles the Swift speech helper and packages with `--mac`.
- `electron-builder.yml` includes the macOS speech helper globally and has no Linux targets.
- `electron/main.mjs` applies macOS window chrome, media permission APIs, Apple Settings links, and Mac-specific error copy.
- `electron/speech.mjs` assumes Swift and `SFSpeechRecognizer` exist.
- `electron/cua.mjs` resolves only macOS CUA paths and sockets.
- The renderer currently infers too much from “running in Electron”; screen preview, dictation, ...
View Raw Thread
Developer & User Discourse
KesleyDavid • Aug 12, 2026
Implementation has started. The maintainer has already confirmed outside GitHub that contributions are welcome, so an additional approval is not a blocker.
The working branch starts from current `main` and targets one complete Ubuntu 24.04 x64 baseline PR: `.deb` + AppImage packaging, Linux-safe Electron behavior, capability-driven fallbacks, documentation, packaging CI, and real Ubuntu launch evidence. Unsupported dictation and local computer control will fail closed without blocking chat, local agent CLIs, Composio, or cloud computers.
I’ll link the draft PR and its test evidence here when it is ready for review.
The working branch starts from current `main` and targets one complete Ubuntu 24.04 x64 baseline PR: `.deb` + AppImage packaging, Linux-safe Electron behavior, capability-driven fallbacks, documentation, packaging CI, and real Ubuntu launch evidence. Unsupported dictation and local computer control will fail closed without blocking chat, local agent CLIs, Composio, or cloud computers.
I’ll link the draft PR and its test evidence here when it is ready for review.
KesleyDavid • Aug 12, 2026
Implementation is now underway in draft PR #32.
The PR delivers the Ubuntu 24.04 x64 baseline as one cohesive review unit, with six atomic commits covering the capability contract, packaging, Linux-safe UX, package/lifecycle tests, documentation, and final native-shell polish.
Local validation is complete on Ubuntu 24.04.4 GNOME Xorg: 92 tests pass, both `.deb` and static AppImage build successfully, all three packaged executable forms pass the lifecycle smoke, and the real UI was inspected with native GNOME chrome.
GitHub CI is now green across macOS, Ubuntu, and Windows. The dedicated Ubuntu 24.04 job also built both artifacts from a clean checkout, validated their metadata/resources, launched the real renderer with the Chromium sandbox active, and proved clean embedded-server shutdown.
The `.deb` is also installed on Ubuntu 24.04.4 GNOME Xorg and was launched through its real desktop entry. The installed harness reports `static: true`, native GNOME chrome renders correctly, and ...
The PR delivers the Ubuntu 24.04 x64 baseline as one cohesive review unit, with six atomic commits covering the capability contract, packaging, Linux-safe UX, package/lifecycle tests, documentation, and final native-shell polish.
Local validation is complete on Ubuntu 24.04.4 GNOME Xorg: 92 tests pass, both `.deb` and static AppImage build successfully, all three packaged executable forms pass the lifecycle smoke, and the real UI was inspected with native GNOME chrome.
GitHub CI is now green across macOS, Ubuntu, and Windows. The dedicated Ubuntu 24.04 job also built both artifacts from a clean checkout, validated their metadata/resources, launched the real renderer with the Chromium sandbox active, and proved clean embedded-server shutdown.
The `.deb` is also installed on Ubuntu 24.04.4 GNOME Xorg and was launched through its real desktop entry. The installed harness reports `static: true`, native GNOME chrome renders correctly, and ...
KesleyDavid • Aug 12, 2026
Wayland baseline progress from PR #32:
- Installed the generated `.deb` on a clean Ubuntu 24.04.4 x64 GNOME/Wayland VM and confirmed `XDG_SESSION_TYPE=wayland`.
- Verified native GNOME chrome, packaged embedded harness startup, capability-aware onboarding, no Linux dictation UI, and **This computer** disabled while cloud/off remain usable.
- Verified clean close and successful launch from the GNOME application menu.
- The manual run exposed a generic launcher-icon defect. Commit `7257adc` fixes it by packaging the existing SVG in the freedesktop scalable icon hierarchy and adds a package-verifier assertion. Reinstallation confirmed the correct launcher and dock icon.
- Local checks after the fix: typecheck, 92 tests, Electron syntax checks, Linux packaging, and package verification all pass.
I am leaving the combined Wayland `.deb` + AppImage checklist item open until the AppImage is also exercised in this real Wayland VM. Authenticated CLI/cloud/OAuth checks also remain unclaimed.
...
- Installed the generated `.deb` on a clean Ubuntu 24.04.4 x64 GNOME/Wayland VM and confirmed `XDG_SESSION_TYPE=wayland`.
- Verified native GNOME chrome, packaged embedded harness startup, capability-aware onboarding, no Linux dictation UI, and **This computer** disabled while cloud/off remain usable.
- Verified clean close and successful launch from the GNOME application menu.
- The manual run exposed a generic launcher-icon defect. Commit `7257adc` fixes it by packaging the existing SVG in the freedesktop scalable icon hierarchy and adds a package-verifier assertion. Reinstallation confirmed the correct launcher and dock icon.
- Local checks after the fix: typecheck, 92 tests, Electron syntax checks, Linux packaging, and package verification all pass.
I am leaving the combined Wayland `.deb` + AppImage checklist item open until the AppImage is also exercised in this real Wayland VM. Authenticated CLI/cloud/OAuth checks also remain unclaimed.
...
KesleyDavid • Aug 12, 2026
Follow-up: the rebuilt `OpenMausBot-0.1.7-x86_64.AppImage` was also exercised in the same clean GNOME/Wayland VM.
- Downloaded it as an ordinary user, set the executable bit, and launched it directly.
- It started without installing FUSE 2 or any additional guest dependency.
- The persisted UI opened with native GNOME chrome and the same fail-closed Linux capability state.
- Closing the window returned to the shell and stopped the embedded server.
The issue's combined Ubuntu Wayland `.deb` + AppImage checklist item is now complete. Authenticated CLI/cloud/OAuth checks remain separate and unclaimed.
- Downloaded it as an ordinary user, set the executable bit, and launched it directly.
- It started without installing FUSE 2 or any additional guest dependency.
- The persisted UI opened with native GNOME chrome and the same fail-closed Linux capability state.
- Closing the window returned to the shell and stopped the embedded server.
The issue's combined Ubuntu Wayland `.deb` + AppImage checklist item is now complete. Authenticated CLI/cloud/OAuth checks remain separate and unclaimed.
The current delivery model is one cohesive draft PR for the complete Ubuntu Desktop baseline, starting from current `main` and organized into atomic commits:
1. portable desktop capabilities and platform guards;
2. Ubuntu `.deb` and AppImage packaging;
3. capability-driven Linux UI and UX;
4. tests, packaging CI, and real Ubuntu runtime evidence;
5. README, CONTRIBUTING, and Linux installation documentation.
The PR will not depend on the competing Windows branches, but shared code will remain platform-neutral so the preferred Windows implementation can be adapted afterward.
Capture, CUA-backed local control, Wayland automation, bundled CUA, Linux dictation, and ARM64 remain follow-up phases on this issue because they require separate security and runtime validation. I’ll cross-reference those follow-ups here when their scope begins.