Melso Docs

Desktop app

Install Melso Desktop, use desktop tabs and the built-in daemon, and connect to a self-hosted instance.

Melso Desktop is available for macOS, Windows, and Linux. It uses the same account and workspace data as the web app, but it manages the daemon on your machine automatically and keeps a separate set of tabs for each workspace.

Desktop and web

WebDesktop
How you open itBrowserInstall the desktop app
Workspace tabsUses browser tabsEach workspace keeps its own set of tabs
DaemonInstall and start the CLI separatelyStarted by the app automatically after sign-in
UpdatesRefresh the pageUpdated through the desktop app

Web is more convenient for a quick look or on a shared computer.

You can be signed in to both at the same time. As long as they connect to the same Melso service, the data they show is shared.

Installation

Pick the installer that matches your OS and CPU architecture from the Melso downloads page:

PlatformInstaller
macOS.dmg
Windows.exe
Linux.AppImage, .deb, or .rpm

After installing, sign in with the same email you use on the web. Once signed in, Desktop starts its own bundled Melso CLI and detects the AI coding tools already installed on the machine.

The CLI bundled with Desktop only serves the app's managed runtime. If you also want to run commands like melso issue in a terminal, install the CLI separately following step 2 of the quickstart.

Desktop tabs

Desktop saves tabs per workspace. For example, if you open three issues in workspace A and switch to workspace B, you see B's own tabs; switch back to A and the three earlier tabs are still there.

A given resource opens only once in the current workspace. Tabs can be reordered, pinned, and closed, and each keeps its own forward/back history and scroll position. Clicking or pasting an app link for this deployment opens it directly in a tab instead of jumping to the browser.

Logging out clears every tab saved on the machine, so the next person to sign in never sees pages left behind by the previous account.

Built-in daemon

After sign-in, Desktop creates a dedicated CLI profile for the current Melso service and uses it to start the daemon. The profile lives at:

~/.multica/profiles/desktop-<host>/

It never reads or overwrites the default profile you use in the terminal. If you also start another daemon manually, Melso shows them as separate runtimes.

You can check runtime status and logs in Desktop's settings. If a tool isn't detected, first confirm it runs in a regular terminal and is logged in, then restart Desktop's daemon.

Updating Desktop

Auto-update is on by default. The app checks for and downloads new versions in the background; once a download finishes you can restart to install immediately or let it install on the next quit. You can also turn off automatic checks or check for new versions manually under Settings → Updates.

Updates are distributed per OS and CPU architecture:

  • Windows arm64 and macOS x64 (Intel) each use their own update feed;
  • all other architectures use the default feed;
  • the app matches the update feed automatically — no manual selection needed;
  • on Linux, auto-update only works for .AppImage; update .deb and .rpm by installing a new package over the old one;
  • if auto-update fails, likewise install over the top with the matching installer from the downloads page.

Connecting to a self-hosted instance

Desktop connects to Melso Cloud by default. To connect to a self-hosted instance, create desktop.json inside the .multica directory of your home directory:

PlatformPath
macOS/Users/<you>/.multica/desktop.json
Linux/home/<you>/.multica/desktop.json
WindowsC:\Users\<you>\.multica\desktop.json

These are the default locations — if your home directory has been moved or redirected, use its actual path.

{
  "schemaVersion": 1,
  "apiUrl": "https://api.example.com"
}

This is not the CLI's ~/.multica/config.json, and the key names differ: the CLI uses server_url, Desktop uses apiUrl. Desktop never reads the CLI's config — it manages a separate daemon profile under ~/.multica/profiles/desktop-<host>/. Editing config.json does not change which server Desktop connects to.

apiUrl is the backend's public address; it is required and must use http or https. The other two URLs can be omitted — Desktop derives them automatically:

  • wsUrl: swaps the apiUrl scheme to ws or wss and appends /ws to the path;
  • appUrl: strips the api. prefix when the host starts with api. and has at least three labels (api.example.comexample.com); otherwise it stays the same as apiUrl.

Usually apiUrl alone is enough. Override explicitly only when the derivation doesn't match your deployment; the three common cases:

  • the web app and the API are on different domains;
  • WebSocket is deployed separately;
  • the host doesn't fit the prefix-stripping convention (two-label hosts like api.local keep their prefix).
{
  "schemaVersion": 1,
  "apiUrl": "https://api.example.com",
  "appUrl": "https://app.example.com",
  "wsUrl": "wss://ws.example.com/socket"
}

Restart Desktop after saving — the file is read once at startup. The two failure modes look different, which is the fastest way to tell them apart:

  • File not found (wrong directory, or a filename that isn't exactly desktop.json) — Desktop uses the default Cloud configuration and shows no error. So if Desktop still reports a Cloud address and no configuration error, the file is not where Desktop is looking.
  • File found but invalid JSON, version, or URLs — Desktop shows a configuration error and does not fall back to Cloud.

Delete the file and restart to return to the default Cloud configuration.

Desktop can only connect to addresses reachable from both the browser and the executing machine. If a remote self-hosted instance doesn't use HTTPS or doesn't proxy WebSocket, Desktop can't establish a connection; see the self-host quickstart for the full configuration.

Windows: check the filename and encoding

Two Windows editor defaults silently produce a file Desktop can't use:

  • Notepad appends .txt. Saving as desktop.json can produce desktop.json.txt, which Desktop treats as not found. Turn on file name extensions in Explorer, or pick All files in the save dialog. To see the real filename, run Get-ChildItem "$env:USERPROFILE\.multica" -Filter "desktop.json*" in PowerShell — the Name column must read exactly desktop.json.
  • PowerShell redirection writes UTF-16 or a BOM. > desktop.json and Out-File can produce an encoding that fails to parse, which surfaces as a configuration error.

To avoid both, create the file from PowerShell in one step:

$dir = "$env:USERPROFILE\.multica"
New-Item -ItemType Directory -Force $dir | Out-Null
$json = @'
{
  "schemaVersion": 1,
  "apiUrl": "https://api.example.com"
}
'@
[System.IO.File]::WriteAllText("$dir\desktop.json", $json)

Windows Defender flags Melso as a virus

Symptom: Windows Security reports a threat such as Trojan:Script/Wacatac.B!ml and quarantines a file inside the Desktop installation. The affected item is normally the bundled CLI, not the app executable:

C:\Users\<you>\AppData\Local\Programs\@multicadesktop\resources\app.asar.unpacked\resources\bin\multica.exe

Melso's production Windows builds are Authenticode-signed and the release workflow verifies the signature before publishing. If Defender still flags a file, first confirm that Windows reports a valid Melso publisher signature and that the SHA-256 matches the public release checksum. Do not add an exclusion when either check fails.

Verify it yourself — the public Melso release channel publishes a checksums.txt covering every CLI archive:

Get-FileHash .\multica-cli-<version>-windows-amd64.zip -Algorithm SHA256

Compare the hash with the matching line in the public checksums.txt.

How to fix:

  1. Restore the quarantined file — Windows Security → Virus & threat protectionProtection history → select the Melso item → ActionsRestore.

  2. Add an exclusion so it isn't quarantined again — Virus & threat protectionManage settingsExclusionsAdd an exclusionFolder, and add both:

    • %LOCALAPPDATA%\Programs\@multicadesktop
    • %APPDATA%\Melso

    Both paths matter: when the bundled CLI goes missing, Desktop downloads a replacement into %APPDATA%\Melso\bin, so excluding only the install folder leaves you in a loop where the replacement gets quarantined too.

  3. Report the false positive to Microsoft at Microsoft Security Intelligence — submit a file, choosing Software developer and Incorrectly detected as malware. That is what gets the detection withdrawn for every user, usually within a few days.

Only add these exclusions if you installed Melso from the downloads page, the signature is valid, and the checksum matches. An exclusion disables real-time protection for everything in that folder.

Next steps