Skip to content

Features

Approvals you can actually see

Helicon surfaces every approval request Muse Code raises, as it arrives, and never batches or bypasses one. The three protocol modes, onRequest, promptUnmatched and denyUnmatched, are mapped one to one, so the app behaves exactly as the CLI would. Allow all exists but sits behind a deliberate opt in.

Last updated · Markdown version

Why this is a design decision, not a feature

An agent with shell and file system access is only as safe as the moment you get to say no. A wrapper that auto approves to keep a demo smooth has quietly removed that moment. Helicon treats the approval as the most important event in the protocol.

The three modes, unchanged

ModeWhat Muse Code doesWhat Helicon does
onRequestAsks before the tool call runsShows the request and waits for you
promptUnmatchedAsks when the call is outside the allow listSame, with the reason shown
denyUnmatchedRefuses anything outside the allow listShows the refusal in the thread
Approval modes are mapped one to one with no reinterpretation.

In practice

  • A waiting thread is marked in the sidebar so you can tell at a glance which one needs you.
  • The request shows the command or edit, not a summary of it.
  • Decisions stay in the thread history, so you can see later what was allowed.
  • Allow all is a dangerous opt in, labelled as such, and off by default.

Frequently asked questions

Can Helicon approve things on my behalf?

Only if you turn on allow all, which is an explicit opt in presented as dangerous. By default every approval waits for you.

Do I lose approvals if I close the window?

No. The request belongs to the session, so reopening the thread shows it still waiting.

Does Helicon change what Muse Code considers safe?

No. The allow list and the modes are Muse Code's. Helicon renders them and sends your answer back.

Same Muse Code. Same subscription. Better interface. 

Free and MIT licensed. Signed Windows installer, universal macOS DMG, and a web build against a daemon you run.