Skip to main content
Early access. GitHub and Slack runs start in a cloud sandbox operated by Mutagent, and cloud sandboxes are not open to every account yet: we are letting accounts in gradually while we test. There is nothing to host, and nobody has to be at a terminal.
The gateway watches GitHub, Slack and your own webhooks, and starts a Helix run when something you named happens. The run works in a cloud sandbox, usually on one of your repositories, the same way mutagent helix does, except nobody has to be at a terminal to start it. Everything the gateway does is workspace configuration. It belongs to one workspace, it is stored in the cloud, and every command below acts on the workspace your CLI is set to.

​
The five things you work with

​
What a trigger is

A trigger pairs three things: an event kind (what to listen for), a repository (where the run works, chosen when you create the trigger), and an instruction (what Helix should do). When an event of that kind arrives and matches the trigger, the gateway starts a run in a sandbox on the repository’s latest default-branch commit, pinned for that run. There is no default repository. Name it with --repo owner/name: any repository the Mutagent GitHub App can reach works, and it is linked to the workspace for you. Or run the command inside a clone of a linked repository and the CLI uses that one and tells you so. A webhook, emit:<kind> or trace.threshold trigger can take --no-repo instead, for runs that need no code. With no repository chosen, the command is refused with repository_required. The instruction is plain language — the same thing you would type after helix -p:
A trigger runs as the person who created it, and only while they are still a member of the workspace. If they leave, its runs stop with run_principal_unavailable rather than running as someone else.
Mentions work before you create anything. A connected workspace already answers @ mentions of the app on GitHub and in Slack. Those built-in triggers are listed alongside yours and are always on. See Triggers and routines.

​
Start here

1

Connect GitHub

Installing the GitHub App is a separate step from signing in with GitHub. You can also connect in the web app, under Configuration › Integrations. See Connecting GitHub and Slack.
2

Check which repositories the app can reach

These are the repositories you gave the app access to on GitHub. To add one, change the app’s access there; mutagent gateway repos grant-more prints the page.
3

Prove it end to end

This starts a real run and waits for it to finish.
At any point, run mutagent gateway with no arguments. It prints what is connected, what is missing, and the exact next command to run.

​
For scripts and agents

Every gateway command takes --json and answers with one envelope:
next names the command to run after a success. On a failure, error.fix holds commands that run verbatim, and error.notes is prose to read rather than run. A failure that no command can resolve has an empty fix and explains itself in notes. Destructive commands (disconnect, repos unlink, triggers delete, routines delete, runs cancel) require -f, --force, with --yes as another name for it. The CLI never asks for confirmation. See mutagent gateway.