[Feature] A desktop control panel so non-developers can run OpenMuse without terminals

[littlegreenman-art]

What outcome should OpenMuse handle?

Starting, stopping and configuring a self-hosted OpenMuse without touching a terminal.

Today, running OpenMuse locally means keeping two or three terminal windows open (pnpm dev, pnpm dev:web, pnpm dev:browser), editing .env by hand to change models, and restarting processes after every change. That's fine for developers, but it's the main thing standing between OpenMuse and people who'd love a personal agent but have never used a terminal. I'm one of those people, and it's where I got stuck.

Proposed behavior

A small desktop companion app that wraps the existing scripts. I have a working macOS menu bar prototype, built with Claude Code:

• One button to start/stop everything: server, web app and browser worker, with a status light for each (off / starting / running / failed + a link to logs).
• Open OpenMuse button that lights up once the web app and server are healthy.
• Model picker: lists local models (LM Studio in my prototype, filtered to models that support tool use), writes MODEL= to .env, restarts the server, and loads the new model in LM Studio right away so the switch is visible.
• Starts the local model server (LM Studio) if it isn't running.
• "Start OpenMuse when I log in" toggle.
• Links to logs and the settings file.

It doesn't change OpenMuse itself: it only runs the existing pnpm scripts and edits .env.

Screenshot of the prototype:

To make it useful beyond my setup, it would need:

• a first-run setup (choose the OpenMuse folder, the CopilotKit key step, generating WORKER_TOKEN)
• support for Ollama and cloud providers, not just LM Studio
• a cross-platform answer, e.g. a Tauri/Electron app, or making this part of the web app itself
• signing and distribution

Happy to share the prototype code if it's useful. I wanted to check whether this fits the project's direction before building it any further.

How would we verify it works?

• From a fresh clone with .env configured: click Start → all three services report healthy → Open OpenMuse loads localhost:8081 and a chat message gets a reply.
• Change the model in the picker → the next request to the model provider uses the new model ID (checked in LM Studio's server log).
• Stop → no OpenMuse processes left listening on 8787, 8081 or 8790.
• Platform dependencies: macOS 14+ for the prototype; LM Studio's lms CLI for the local model features.

---

Co-signed,
Zach, who wanted this
Claude (Claude Code, Anthropic), who built the prototype

[kvnloo]

I think this fits well if the desktop app stays a control surface rather than becoming a second configuration/runtime owner.

The contract I'd want is:

• one canonical service reports starting | healthy | failed | stopped plus a bounded error reason;
• model/provider configuration is changed through one validated config path;
• restart returns a receipt for the configuration revision it actually loaded;
• the desktop UI only projects those states and invokes start/stop/config actions.

That avoids "green light but wrong process/model actually running" drift from separately editing .env, starting LM Studio, and inferring health from process existence.

A first slice could be only start/stop/health/logs. Model switching can follow once there is one authoritative config + loaded-revision handshake.

[littlegreenman-art]

Thanks for the thoughtful reply, this makes a lot of sense. "Green light but wrong model actually running" is exactly the bug I hit while testing the prototype: the panel said Gemma while LM Studio still had Qwen loaded, and it took digging through LM Studio's server log to prove which model the next request used. Having OpenMuse report what it actually loaded would have made that obvious.

Agreed on scope. Here's how I'd picture the first slice (start/stop/health/logs only):

• A small supervisor inside the repo (e.g. pnpm openmuse) that owns the API server, web app and browser worker processes.
• It exposes a loopback-only control endpoint: status per service (starting | healthy | failed | stopped + a short error reason), start/stop, and recent log lines.
• Health comes from each service's own health check (/api/health, the worker's /health), not from "the process exists".
• The desktop app just displays that status and calls start/stop. No .env edits, no process management of its own.

Model switching would wait for the validated config path + loaded-revision receipt, as you suggested.

Two questions before anyone writes code:

1. Is a separate supervisor process the right home for this, or would you rather it live somewhere else (e.g. inside the API server)?
2. Is this something the maintainers would want as a PR? Happy to start small once there's a thumbs-up.

Co-signed,
Zach
Claude (Claude Code, Anthropic)