Automate dotMux with Shortcuts

dotMux publishes App Intents, so Shortcuts, Siri, and automations can drive it. There are two actions:

• Open dotMux and Connect to Host — opens dotMux on a saved host, optionally running a command there. This is the “show me a terminal” action, and the one with a Siri phrase.
• Run Command in Background — runs a command on a saved host without opening the app and hands the result back to your shortcut as Output, Error Output and an Exit Code, so you can branch on it, notify on it, or feed it onward.

Both take a tmux Session: leave it empty for the session dotMux would open anyway, or name one, and it’s created if it doesn’t exist.

Where the command runs when the app opens

Give Open dotMux and Connect to Host a command and Run In picks where it goes:

• A new tmux window (the default) — opens a window for the command and switches to it. Name it with Window Name (empty gives dotMux-<date>-<time>), and If That Window Exists picks between running in it again, output and all, or adding a numbered one beside it (build, build-2, …).
• The current pane — types the command into whatever the session is showing, including a program that’s already running. On a host that doesn’t use tmux, this is the only choice.

If the window isn’t at a shell prompt, dotMux asks before interrupting what it’s running; turn on Stop Running Process to stop it without asking.

Two ways to run in the background

The background action’s Run parameter picks between them:

• In the background (the default) — waits for the command to finish, subject to a timeout you set, and returns its output. Right for a check: disk space, a health endpoint, a queue depth.
• In a tmux window — starts it in a detached tmux window and returns immediately. It keeps running after the connection closes, which is what you want for a deploy or a build. Name the window with tmux Window and choose whether a repeat run reuses it or opens a numbered one beside it. If that window is busy, the run fails unless Stop Running Process is on.
• In a herdr pane — the same, on a herdr host.

Letting an automation use a credential

An automation that fires while your phone is in your pocket can’t answer a Face ID prompt — a background process has no screen to show one on. So unattended use is opt-in per credential, from Settings → Security → Credentials → Background use:

• Never (the default) — Face ID every time, as in security. Shortcuts that need this credential in the background will refuse, and say so.
• While this device is unlocked — automations can use it whenever the device is unlocked.
• Anytime, even locked — also runs with the device locked in your pocket, for triggers like a time of day or arriving somewhere.

The boundary is enforced by the iOS Keychain itself, not by an app-side flag: at “While unlocked”, a locked-device run is refused by the system regardless of what dotMux does. Two things worth knowing before you raise a credential: anything above “Never” also stops dotMux asking for Face ID when you connect with that credential by hand, and the choice is per credential — so a dedicated automation key, scoped on the server, is a better fit than opening up the key you use everywhere.