DEV Community: Harjot Rana

How to run Muse Code on a remote server over SSH, with a desktop GUI

Harjot Rana — Mon, 28 Sep 2026 04:59:12 +0000

Your code lives on a server: a beefy dev box, a cloud VM, the machine under your desk. You want Muse Code to work there, where the files, the toolchain and the CPU are. But you'd rather not spend the day in an SSH terminal scrolling back through agent output.

Helicon 0.18 adds SSH projects: you pick a folder on a remote machine, and Helicon runs Muse Code there over ssh, while you get the desktop app on your laptop: threads in a sidebar, readable approvals, and inline diffs.

This guide sets it up in about 10 minutes.

How it works

When you start a thread in an SSH project, Helicon runs this on your laptop:

ssh <host> 'cd /path/to/project && exec muse serve'

Muse Code runs on the server, inside the project folder, and talks to Helicon over the SSH connection using the Muse Session Protocol (MSP), the same protocol it speaks to any local client. Nothing is synced or copied: the code never leaves the server.

A few consequences worth knowing:

The server's Muse login is the one used. Whatever account you signed into with muse login on the server is what your SSH threads run on. Helicon's local account profiles don't apply to SSH projects.
Your laptop needs to stay connected. Muse runs as part of the SSH session, so if your laptop sleeps or the network drops, that session ends. Helicon notices within about 45 seconds.
Your SSH config is respected. Host aliases, ports, users, jump hosts and keys all come from ~/.ssh/config, the same as when you type ssh yourself.

1. Make `ssh` work without a password

Helicon never types a password or answers a prompt; it runs ssh in batch mode. So the first step is a key.

On your laptop:

ssh-keygen -t ed25519            # skip if you already have ~/.ssh/id_ed25519
ssh-copy-id you@devbox.example.com

Then give the host a short name in ~/.ssh/config:

Host devbox
  HostName devbox.example.com
  User you
  IdentityFile ~/.ssh/id_ed25519

Check it: this should print ok without asking you anything.

ssh devbox echo ok

If it asks you to confirm the host key, answer yes once. Helicon can't answer that question for you, and will tell you so if you skip it.

On Windows: Helicon uses Windows' own OpenSSH (ssh.exe), not the one inside WSL. Keys and config belong in %USERPROFILE%\.ssh. If your keys only live in WSL, copy them over, or run ssh-keygen in PowerShell.

2. Install Muse Code on the server

On the server, install the muse CLI the way you normally would, then sign in once:

muse login

Now make sure muse is on the PATH for non-interactive SSH commands, which is what Helicon uses. From your laptop:

ssh devbox 'command -v muse'

If that prints nothing, your shell only sets PATH for interactive logins. Add the folder that holds muse to your PATH in ~/.zshenv (zsh) or near the top of ~/.bashrc (bash), and try again.

3. Add the project in Helicon

Open Helicon (0.18 or newer) and click Add project.
Choose SSH host.
Type the host: devbox, or you@devbox.example.com.
Browse the server's folders, starting at your home folder, and pick the project.

The project shows up in the sidebar like any other. Start a thread, and Muse Code is working on the server.

When something goes wrong

Helicon reports what ssh itself said, so the error usually tells you the fix:

Helicon says	Fix
Host key verification failed	Run `ssh devbox` once in a terminal and accept the host key
Permission denied (publickey)	The key isn't on the server: rerun `ssh-copy-id`, or check `IdentityFile`
Could not find ssh on this machine	Install OpenSSH (on Windows: Settings, Optional features, OpenSSH Client)
Connection refused / timed out	Check the host, port and VPN with `ssh devbox echo ok`
Muse not found when starting a thread	`ssh devbox 'command -v muse'` prints nothing: fix PATH as in step 2

What SSH projects don't do yet

In 0.18, SSH projects run threads, show diffs and approvals, and list past sessions from the server. These aren't available for them yet:

the file viewer panel
the skills list
attaching files (images still work)
creating a new remote folder or cloning a repo onto the server from Helicon

Create folders and clones over SSH first, then add them.

SSH projects or the remote daemon?

Helicon has two ways to use a remote machine:

SSH projects (this guide): the Helicon app runs on your laptop, and only Muse runs on the server. Mix local and remote projects in one window.
Remote daemon: the whole Helicon server runs on the remote machine, and you open it in a browser. Better when you want to reach it from any device.

Try it

Helicon is free and open source (MIT) for Windows, macOS and Linux: helicon.sh. SSH projects were contributed by Hoà Dinh in #56.

Helicon is an unofficial community project, not affiliated with Meta.

I built a desktop app for Meta's Muse Code CLI, and the billing is the whole story

Harjot Rana — Tue, 15 Sep 2026 23:25:08 +0000

Meta shipped Muse Code in August: a coding agent that lives in your terminal, with a subscription starting at five dollars a month. The model is good. The harness runs subagents in parallel and keeps an append-only event log you can replay.

Two things about it bothered me enough to spend a fortnight on them.

It is terminal-only. And on Windows there is no native build at all, so several comparison guides now tell readers that if they are on Windows or want a desktop app, they should pick a competitor.

So I built Helicon: an open-source desktop and web client for the actual Muse CLI. This post is about the one design decision that shaped everything else, because it is the part I got wrong first and the part most people get wrong when they wrap a CLI.

The mistake I made first: scraping the terminal

The obvious way to put a UI on a CLI is to spawn it in a pty, parse what comes out, and render that.

I did this. It took an afternoon and it worked, in the way that a demo works.

Then I tried to implement approvals. The agent wants to run npm test, and the user needs to allow or reject it. In a scraped terminal, "the agent is asking for approval" is a string you pattern-match out of ANSI escape codes, and your answer is keystrokes you write back into a pty. You are inferring a security decision from formatted text. Every output tweak upstream becomes a correctness bug in your client, and some of those bugs run commands nobody approved.

I deleted it.

What replaced it

Meta publishes the Muse Code SDK, MIT licensed, for programmatically driving Muse over the Muse Session Protocol. The CLI itself exposes muse serve, which speaks that protocol over stdio.

So Helicon's daemon spawns one muse serve host per workspace and talks MSP to it through the official SDK. Muse is the agent. Helicon is a client.

That means approvals arrive as protocol events, not as parsed text. Diffs arrive as structured data. Sessions that were started in the terminal show up in the sidebar with their history, because the CLI already wrote them to disk in a format the protocol can read back. Nothing is inferred from what the screen happened to look like.

The rule I would give anyone wrapping a CLI: if the vendor documents a protocol, the protocol is the only surface that stays where you left it. Output formatting is not an API, no matter how stable it looks today.

The part that decides your bill

Here is the thing I did not expect to be the most important feature.

Muse Code subscriptions only bill through Muse's own harness. If you point a generic OpenAI-compatible client at the API, you are on pay-as-you-go rates instead. Same model, different bill.

I have watched people work this out the hard way in public and reach the wrong conclusion. One thread has a user stating, twice, that a Muse Code subscription "can not be used in any kind of GUI harness" and that you have to go pay-as-you-go to use it anywhere but the terminal. Another person in the same thread confirms the symptom: using the vendor's harness deducts from the plan, and every other option lands on the API.

The observation is correct. The conclusion is not.

The subscription is not terminal-locked. It is harness-locked. Once you stop trying to replace the harness and start driving it instead, a GUI costs nothing extra, because the work is still going through Muse with your own muse login.

That is the entire argument for this architecture, and it is worth more than any UI feature I could build. If your wrapper reimplements the agent loop against the raw model API, you have quietly moved your users onto a second bill for a model they already pay for.

Windows, honestly

Muse has no Windows binary. That is not something a client can fix.

What Helicon does is more boring than "Muse Code on Windows" sounds. The daemon runs natively on Windows, and when it needs the agent it runs:

wsl -d Ubuntu -- muse serve

Then it translates paths in both directions, because the daemon thinks in C:\Users\you\project and the agent thinks in /mnt/c/Users/you/project. Get that wrong and every file operation lands somewhere plausible and wrong.

export function toWindowsPath(wslPath: string): string {
  const match = wslPath.match(/^\/mnt\/([a-z])\/(.*)$/);
  if (!match) {
    throw new Error(`Cannot map to Windows: not a /mnt/<drive> path: ${wslPath}.`);
  }
  const drive = match[1].toUpperCase();
  const rest = match[2].replace(/\//g, "\\");
  return `${drive}:\\${rest}`;
}

Note the throw. An unmappable path is a bug, not a thing to guess at.

So WSL2 is still required, and I say that on the landing page, in the install steps and in the FAQ. What changes is not the requirement. It is that you stop living in an Ubuntu terminal on your own machine to use a tool you pay for. The installer is signed and auto-updates, which on Windows matters more than people from other platforms expect.

Bundling the runtime

The daemon is Node. Until last night, that meant a user had to install Node 22 or newer before Helicon would start, and on Windows they had to install it on the Windows side rather than inside WSL, which is exactly the kind of instruction that loses people.

The fix is a Tauri sidecar. A build script downloads a pinned Node build, verifies its SHA256 against the published checksums, and drops it in src-tauri/binaries/node-<target-triple>. For universal macOS builds, lipo merges the two architectures. At boot the app prefers the binary next to its own executable and only falls back to a system Node if that is missing.

It costs about 30MB on the Windows installer. It removes an entire step from the install instructions, and an entire category of "it doesn't launch" issue. Worth it.

One detail worth copying: the bundled runtime's folder is deliberately left off the PATH handed to subprocesses. Users run shell commands through the app, and their node should be their node, not mine.

What it looks like

Projects grouped by folder, worktrees included. Threads with inline diffs where the edit happened. Approvals surfaced the moment they arrive, never batched, never bypassed. A cost view that shows what each thread would have cost at published API rates, so "is this plan worth it" becomes a number instead of a feeling. Command palette, slash commands, full keyboard operation.

The same React UI ships twice: as a Tauri desktop app, and as a web app pointed at a remote daemon. One codebase, two shells.

Honest gaps

The macOS builds are not Apple-notarized yet, so the first launch needs a right-click and Open. Linux has no packaged build, only a source path. The SDK is a developer preview, so the protocol can move under me. And Helicon is not the only GUI in this space — there are several, including ACP adapters for Zed and JetBrains, and an unofficial VS Code extension. If you want Muse inside your editor, use those. Helicon is for people who want a standalone workspace.

It is free, MIT licensed, and unofficial: not made, sponsored or endorsed by Meta.

github.com/HarjjotSinghh/helicon · helicon.sh

If you use Muse Code on Windows, I would like to know what breaks. That is the platform I have tested most and can verify least.

I mined 1,398 corrections out of my coding agent logs and turned them into a rules file

Harjot Rana — Thu, 10 Sep 2026 13:08:17 +0000

My coding agent asks me the same things constantly. New file or add to the existing one. Do you want a test for this. Should I clean up the function next to the one I am touching.

I have answered all of these. Dozens of times. The answers were sitting in my chat history and nobody, me included, was reading them back.

So I wrote a tool that does.

What it actually is

jot is an extractor plus a knowledge base. The extractor finds the session stores your coding agents leave on disk, reads them, and pulls out the moments where you stopped the agent and said no, do it this way instead. Those get clustered into rules, each with a reason and a stated exception, and written to markdown.

You load that markdown as an agent skill. Your agent reads it before it starts working.

npx skills add HarjjotSinghh/jot -g

Then in any agent that supports Agent Skills:

/jot should this state be global or local?
/jot review this PR
/jot which model should these subagents run on?

That command installs mine, which is really a worked example. The part worth your time is pointing the extractor at your own logs.

No training. No GPU. No fine-tune. Text files.

The version I sat on for a year

For about a year I wanted to fine-tune a small model, 8B to 20B, on every file I own. Text, audio, PDFs, spreadsheets, decks. A model of me, trained on me.

I never wrote a line of it. Not once did I open a terminal.

Then I read Kun Chen's post about distilling himself into a skill, and the thing that clicked was that the hard part of "clone yourself" was never the weights. It was the preferences. And preferences are small enough to just write down.

By preferences I mean the boring calls with no correct answer, only my answer. Refactor now or ship and come back. Test first or backfill before merge. Ask before touching anything with real users on it, or just go. A generic model has a sensible default for every one of these. Several of mine are not the default, and that gap is the entire reason the agent keeps interrupting me.

Do not interview yourself

The obvious way to build this is to sit with a model and answer questions about how you work. It produces beautiful, useless output, because everyone is aspirational about themselves.

Ask me if I write tests first and I will say yes with a straight face. Look at what I actually shipped and you find spikes with no tests and coverage backfilled right before merge. The second version is the true one.

So I skipped the interview and went to the logs.

The highest-value thing on my disk is not my code. It is every time I typed something at an agent that was one keystroke away from doing the wrong thing. Every agent saves those. Nobody reads them back.

The extraction

Six adapters: Claude Code JSONL, Codex rollouts, Grok history, Gemini CLI logs, OpenCode, and Cursor, which stores every message as a row in a 1.5 GB SQLite file.

python scripts/extract_corpus.py
python scripts/extract_corpus.py --agents claude codex cursor --min-score 5

The pipeline:

Normalize everything to turns. Six agents, six schemas, one shape.
Pair each thing I said with the agent turn it was reacting to. "No, not like that" is meaningless on its own. It only carries information next to the thing it rejected.
Score against a lexicon weighted toward corrections, rejections, and stated preferences.
Dedupe hard, because I complain about the same three things constantly and 40 instances of one gripe is one rule, not 40. First pass: 1,398 distinct judgment events across 1,290 conversations. 505 corrections. 380 stated preferences.

Every rule in the knowledge files carries an evidence tag pointing back at the source:

[observed Nx] extracted from N distinct real sessions, dated
[stated] I wrote it down as a rule
[inferred] derived from adjacent behaviour, lower confidence, flagged at use time A rule with no evidence is a vibe. If it cannot be traced, it does not go in.

Layout

A thin skill stub, and a knowledge base that lives in the repo.

skills/jot/SKILL.md   loader; local checkout first, raw repo URLs second
ENTRY.md              routing table plus the decision procedure
PRINCIPLES.md         durable rules that survive a framework change
ENGINEERING.md        backend, debugging, git, review
FRONTEND.md           visual taste, design parity, slop detectors
AGENTIC.md            model routing, autonomy grants, parallelism
WORKFLOWS.md          named sequences: feature, bug, refactor, review, EOD
TOOLS.md              what I reach for, and the friction I hit
BOUNDARIES.md         hard stops, read before anything outward-facing
VOICE.md              how I write; loaded only for text going out under my name
OPERATING.md          attention, cadence, escalation
CONTEXT.md            who I am, what is active
state/                mined evidence, changelog, pending promotions
bench/                the benchmark that says whether any of this works

The stub never changes. All churn happens in the knowledge files, so every agent pointed at the repo stays in sync without a separate update step.

private/ and state/evidence/ are gitignored and never fetched over the network. The public layer holds preferences. The private layer holds the specifics that make them actionable: named colleagues, clients, money, positioning. The skill only loads those from a local checkout.

Does it work

A rules file that sounds like you but decides differently is worse than no file at all. It makes confident wrong calls in your name and you are not there to catch them. So bench/ answers the question properly.

Three arms. A control model with no skill. The same model with /jot loaded. And me, answering blind.

python scripts/bench_run.py --set v1
python scripts/bench_score.py --run <timestamp>

Ten questions, each one a decision where a competent generic model has a plausible default that is not what I actually do. Both model arms run in clean-room sessions that never saw the conversation where the rules were written, because a session that helped write the answers already knows the answers. Their responses go into sealed files I do not open until I have committed to mine.

Scored 0 to 2 against my answer. Minus one for fabricating a preference I do not hold.

First run: skill 13/20, control 7/20.

The number that matters is the delta between the two model arms. A skill that scores well only because any competent model would have scored well is recording things that did not need recording.

Then I sorted the results by where each rule came from

I had written two kinds of rules without really noticing. Ones mined out of real transcripts, and ones I had simply believed about myself and typed in.

mined from transcripts:  2, 2, 2, 2
believed about myself:   0, 1, 0, 0

No exceptions in either direction. The mined rules carried the entire gain. Everything I had assumed about myself was dead weight or actively wrong, and it was wrong in exactly the same confident tone as the stuff that was right.

The worst one: my file said that once I give a blanket approval, the agent should stop asking. I had generalized that from exactly one line I typed mid-task, once. The benchmark asked what to do at a sub-decision that approval never covered. The skill told the agent not to ask. My real answer was "I would ask first."

One occurrence is an anecdote. My own precedence rules say three occurrences make a rule. I broke my own precedence rules inside the file that contains them.

That is how this goes wrong. Not by being wrong about you. By being right about you in one situation and then applying it everywhere.

Patched four rules, re-ran, 18/20

And one question that had scored 2 dropped to 0.

The rule I added to fix "just take the two-hour refactor now" got applied to a two-minute fix on a live customer list. Which is the opposite of what I do, because that is not my code and those are somebody's real customers.

A rule that fixes one case and breaks another is written too broadly. Misses now become golden cases in bench/golden/, and each one turns into a rule with an explicit Doesn't apply when line. Boundaries outrank every principle in the repo instead of politely tie-breaking with them.

What it is like to use

Uncanny. Not "wow, impressive model" uncanny. Specifically: you ask it something you have never thought about before, it answers, and you get a small jolt of yes, that is exactly what I would have done, and that is exactly why.

It is talking to yourself, except this version of you has read every correction you have ever issued and never gets tired.

It disagrees sometimes, and the disagreements turned out to be more useful than the agreements. It was never being stupid. It was faithfully applying a rule I had written badly. The gap between the two model arms measures my preferences. The gap between the skill and me measures my writing. Two different problems, fixable separately.

Worth doing even if nobody else installs it. Writing a rule with a reason, a stated exception and a piece of evidence forces you to find out whether you actually hold it. A few of mine did not survive the format.

Not bad for an idea I sat on for a year because I thought it needed a GPU.

Try it

npx skills add HarjjotSinghh/jot -g

Repo: https://github.com/HarjjotSinghh/jot

Prior art: https://github.com/kunchenguid/kun, which made the case that the repeatable part of your judgment is worth externalising, and that it was never the part that was your moat. Read Kun's first.

If you run the extractor on your own logs, I want to know two things. How many events it found, and how many of the rules you wrote by hand survived contact with a benchmark. My guess is fewer than you expect.

How we built a 14-agent pipeline that ships a deployed app + launch assets in ~7 minutes

Harjot Rana — Mon, 01 Jun 2026 01:54:28 +0000

Most AI app builders stop at "deployed." You prompt, you get a repo, maybe a preview URL, and then the actual work starts: wiring a domain, writing the landing copy, cutting screenshots, drafting the launch thread. We wanted the pipeline to stop at "launched" instead, so we built one. This is how it works under the hood, including the parts that broke.

The product is Moonshift. One prompt triggers 14 specialized agents across 10 phases. Average run is ~7 minutes and ~$3 in API spend, with a hard $5 ceiling that aborts the run. Everything ships to your Vercel, your GitHub, your database. This post is the engineering, not the pitch.

The core problem: parallel agents drift

The naive version of "many agents build an app" falls apart fast. If a backend agent and a frontend agent both work from a vague English spec, they invent incompatible contracts. The backend returns { user_id }, the frontend reads userId, and you find out at runtime in production.

Our fix is a planner that emits a JSON contract first. Before any code is written, one agent produces a typed contract: routes, request/response shapes, table schemas, env vars, page list. That contract is the single source of truth. Backend, frontend, database, and test agents all build against it in parallel instead of against prose.

Then a contract-validator agent runs after the parallel build and diffs the actual code against the contract. When the frontend's fetch shape doesn't match the backend's handler, the validator doesn't just flag it. It patches the mismatch. This one agent removed the largest single class of "looks done, 500s on click" failures we had.

The 10 phases

Plan - generate the JSON contract.
Scaffold - lay down the framework skeleton (Next.js, config, deny-globs that protect files agents shouldn't touch).
Backend - API routes and server logic against the contract.
Frontend - pages and components against the same contract.
Database - schema + migrations (Drizzle + Turso).
Validate - contract-validator reconciles 3-5 in parallel, auto-fixes drift.
Test + fix - generated tests run; a fixer loop addresses failures.
Deploy - ships to your Vercel via your token.
Audit - security and a11y passes on the live deployment.
Market + publish - a marketer agent drafts X and LinkedIn launch posts in your voice, image-gen produces hero images, and a publisher gates everything behind your one-tap approval.

The interesting phases are 6, 7, and 10. Everyone has a code-gen step. Almost nobody has a reconcile step, a real fixer loop, or a phase whose only job is launch assets.

Reliability: not every failure is equal

Long multi-agent runs fail in boring ways: a rate limit, a flaky deploy, a model that returns prose where you asked for JSON. If you retry all of them the same way, you either give up too early on transient errors or burn money death-looping on deterministic ones.

We run a failure classifier that buckets every failure into transient, deterministic, or permanent:

transient (429s, network blips, stream idle) - retry with backoff.
deterministic (a test that fails the same way every time) - hand to a fixer agent, don't blindly retry the same call.
permanent (bad auth, missing token) - stop and surface it. No point spending more.

Retries are capped on three axes at once: per-phase, per-agent, and a global per-run ceiling. The global cap is what keeps a single bad run from quietly turning into a $40 bill. Combined with the hard $5 abort, the worst case is bounded and visible instead of a surprise invoice.

A subtle one we hit: a long LLM stream can go idle without erroring (the upstream connection gets severed but the socket never closes). A naive loop waits forever. We added an idle watchdog in the agent loop so a silent stall is treated as a transient failure and retried, instead of hanging the whole run.

Design constraints that shaped everything

Your infra, zero lock-in. Code lands in your GitHub, the app deploys to your Vercel, the database is yours. Cancel the subscription and you keep a working product. This forced the deployer to operate purely through user-supplied tokens, which is more work than deploying to our own infra but is the entire point.
The publisher physically cannot post without you. Social publishing is gated per post, per platform, behind an explicit human tap. Autonomy ends at the point where it would speak as you in public. Generation is automatic; publishing is not.
Hard cost ceiling. $5/run, enforced mid-run, not reconciled after. Agents check remaining budget before expensive calls.

Stack

Next.js for web, Drizzle + Turso (libSQL) for data, Playwright for browser automation in the marketing/audit phases. The orchestrator is a separate runtime from the web app, spawned per run from source so a fix ships without a full rebuild.

Honest lessons

A typed contract beats a smarter prompt. We spent weeks trying to make agents "just agree." Making them agree on a machine-checkable artifact was the actual fix.
A reconcile phase is worth more than a better code-gen model. Catching drift after the fact, cheaply, beat every attempt to prevent it perfectly up front.
Classify failures before you retry them. Uniform retry is how multi-agent systems burn money and still fail.
Bound the blast radius in money, not just time. A per-run dollar cap is the single most important guardrail in an autonomous pipeline that calls paid APIs in a loop.

If you want to see the output, the first run is free with your own API key at moonshift.io. Happy to answer architecture questions in the comments.

DEV Community: Harjot Rana

How to run Muse Code on a remote server over SSH, with a desktop GUI

How it works

1. Make ssh work without a password

2. Install Muse Code on the server

3. Add the project in Helicon

When something goes wrong

What SSH projects don't do yet

SSH projects or the remote daemon?

Try it

I built a desktop app for Meta's Muse Code CLI, and the billing is the whole story

The mistake I made first: scraping the terminal

What replaced it

The part that decides your bill

Windows, honestly

Bundling the runtime

What it looks like

Honest gaps

I mined 1,398 corrections out of my coding agent logs and turned them into a rules file

What it actually is

The version I sat on for a year

Do not interview yourself

The extraction

Layout

Does it work

Then I sorted the results by where each rule came from

Patched four rules, re-ran, 18/20

What it is like to use

Try it

How we built a 14-agent pipeline that ships a deployed app + launch assets in ~7 minutes

The core problem: parallel agents drift

The 10 phases

Reliability: not every failure is equal

Design constraints that shaped everything

Stack

Honest lessons

1. Make `ssh` work without a password