Why I kept Muse Code's approval prompts in Helicon

I built Helicon, a free and open source desktop app for Muse Code, Meta's terminal coding agent. It is unofficial and not affiliated with Meta. I built it to run Muse Code on Windows without WSL, to see every thread in one place, and to keep my own muse login.

Approvals were the part I thought about most.

Muse Code asks before it runs a command or changes a file that its rules do not already allow. In a terminal, that question shows up inside the session you are looking at. Run two or three sessions and the one that is waiting can scroll out of sight while you work in another. The thread just sits there. Nothing tells you it is stuck.

Helicon treats a waiting approval as a state the thread is in. A thread that needs you gets marked in the sidebar, so you can see what is waiting without opening each session. Running threads are marked too, so each row in the list reads at a glance.

I thought about desktop alerts for every prompt. They would get noisy fast when several threads are waiting at once, so the signal stays in the sidebar, where you look when you choose to.

When you open the thread, the approval shows the exact command or the edit before it runs. You allow it or you deny it. I wanted the prompt to show the real thing and not a summary, because a summary is where a bad command can hide.

Each edit also appears as a diff at the turn that produced it. The approval and the change it allowed sit in the same thread, so you do not have to go looking for either.

The rules come from Muse Code, and Helicon passes them through unchanged. The permissions menu has the same modes the CLI has:

• Ask first (onRequest): Muse asks before anything that needs approval.
• Ask for unlisted (promptUnmatched): commands your rules allow just run, and anything else asks.
• Deny unlisted (denyUnmatched): commands your rules allow just run, and anything else is refused.
• Full access (allowAll): everything runs without asking.

There is also a YOLO switch for the full muse --yolo setup: no approvals, no sandbox, trusted workspace. A contributor built it, and it sits behind a confirmation in the permissions menu and in Settings. Turning it off puts back the modes you had before. I get why people want it. After a few approvals in a row, clicking allow starts to feel like a chore. I still keep a little friction on the commands that matter, so I leave it off.

A GUI does not solve the hard part, either. The sidebar marker helps you find the thread. It does not decide for you. If you approve a bad command at speed, the app shows it to you clearly and then lets you approve it anyway.

If you run one session at a time, the marker adds little. It starts to matter when several threads are going at once and you are switching between them. That is the setup I built for.

Here is how I work with it:

1. 1Give each task its own git worktree, so two agents never edit the same files. The parallel agents guide has the commands.
2. 2Start the threads, then watch the sidebar instead of the terminals.
3. 3When a thread is marked, open it. Read the command or the diff, then allow or deny.
4. 4After a run, read the diffs turn by turn. A change that surprises you sits next to the turn that made it.

There are limits. Allow once covers that one call, and allow for this session covers that thread only, so neither carries over to a terminal session on the same project. Always allow saves a rule in Muse Code itself. Helicon follows what the CLI reports, so if Muse Code changes its approval modes, what Helicon shows changes with them.

Helicon is MIT licensed. The source is on GitHub, so you can check how the prompt is drawn for yourself. If you want the setup steps first, the parallel agents guide and the review guide are the next two reads.