What is Mjolnir?
Mjolnir (mj) is a session manager for coding agents that provisions their
execution environments and lets you continue work across harnesses, accounts,
and machines. It supports Codex, Claude Code, Kimi Code, Grok Build, Muse
Code, OpenCode, MiMo Code, and DSH through the Agent Client Protocol (ACP), with a terminal dashboard,
personal web viewer, and desktop app.
Choose a harness account independently from the target where it runs. Mjolnir provisions containers or instances, synchronizes credentials, and can move the session to another compatible target or harness. Same-harness resume restores native session state; cross-harness resume preserves the visible conversation and repository state and supplies a condensed handoff to the new harness.
Mjolnir is designed for the point where “one agent in one terminal” stops scaling: several accounts, several repositories, several machines, and work that should continue after the terminal window closes.
Mjolnir 2.x is a new product generation. It is a session control plane, not a continuation of the 1.x interactive client. Concepts and configuration from a 1.x installation should not be copied into a version 2 configuration.
How the pieces fit together
Section titled “How the pieces fit together”A Mjolnir installation has four main parts:
- The controller daemon owns the local session database, provisions targets, synchronizes credentials, and serves the web viewer.
- A target is the place where a session runs: a local checkout or clone, a container, a named SSH machine, or an EC2 instance.
- A session worker runs on that target beside the selected harness. It owns the durable command queue and event journal, so it does not depend on an attached terminal client.
- The terminal dashboard, web viewer, and desktop app are clients of the daemon. Detaching a client does not stop the session.
A profile selects a harness account, and a target selects the execution boundary. Managed container and EC2 sessions use a bundle describing the repositories in their workspace; bare sessions instead select an existing Git project directory. See Profiles and harnesses, Workspaces and bundles, and Targets.
Mjolnir is built to:
- run many concurrent sessions and keep their prompts, output, and queued work durable;
- pair unrestricted agent modes with disposable, isolated targets;
- checkpoint a session into a verified recovery archive and resume it on a freshly provisioned target;
- keep one canonical harness profile on the controller while synchronizing an allowlisted subset into live sessions;
- show sessions, target capacity, account quota, and credential status in one control plane;
- fail visibly when a checkpoint, target operation, or version boundary cannot be proved safe; and
- remain usable by people through the terminal and web surfaces, and by coding agents through machine-readable diagnostics and a scriptable CLI.
Non-goals
Section titled “Non-goals”Mjolnir deliberately does not try to be all of the following:
- A coding agent. It does not plan work, edit code, or select a model on your behalf. The configured harness does that.
- A privileged host installer. It does not install Podman or Docker, edit
subordinate-ID mappings, create AWS networking, or make an SSH host
reachable.
mj doctorchecks prerequisites and reports remediations. - A machine-cloning tool. It does not copy an entire home directory into a target. Shell startup files, SSH and GPG keys, editor state, cloud configuration, and arbitrary package credentials are outside the profile staging contract.
- A multi-user team service. One per-user daemon owns the session store. The web viewer is a personal remote control with one viewer trust domain, not an authorization system for a team.
- A scheduler. Mjolnir reports target capacity but does not load-balance or reject work based on utilization.
- An in-place target manager. Disposable containers and instances are rebuilt from recovery archives. Packages and files outside the declared workspace are not durable target state.
- A best-effort format converter. Unsupported relay and recovery formats are rejected rather than partially restored.
Supported harnesses
Section titled “Supported harnesses”These are the integrations shipped with Mjolnir 2.x today:
| Harness | Config value | Credentials | Quota view | Native state in checkpoints | Guardian approvals on raw targets |
|---|---|---|---|---|---|
| Codex | codex | Yes | Yes | Yes | Yes |
| Claude Code | claude | Yes | Yes | Yes | Yes |
| Kimi Code | kimi | Yes | Yes | Yes | No |
| Grok Build | grok | Yes | Yes | Yes | Yes |
| Muse Code | muse | Yes | Yes | Yes | No |
| OpenCode | opencode | Yes | No | Yes | No |
| MiMo Code | mimo | Yes | No | Yes | No |
| DSH | dsh | API key | No (usage-priced, shows API) | Yes | No |
“Native state” means Mjolnir can resume the harness’s own session when the same harness is selected again. A cross-harness resume instead restores the workspace and supplies a size-bounded handoff derived from the canonical transcript. See Durability and recovery.
Kimi Code does not provide a guardian approval mode, and OpenCode, MiMo Code, and DSH run commands on the host without a sandbox. None of them should be used on a bare, unsandboxed runtime. Muse Code and MiMo Code currently accept one workspace root, so use either a one-repository bundle or one bare project directory, without attached directories.
Supported machines and runtimes
Section titled “Supported machines and runtimes”A machine is a host: local (this computer), ssh (a named host), or
aws-ec2 (a launch template). A runtime says how the session runs on it.
| What you get | Runtime | Machine | Execution policy | Session boundary |
|---|---|---|---|---|
| Local checkout or isolated clone | bare | local, on a Linux or macOS controller host | Configured approvals | Existing directory or independent clone under .mj/clones/ |
| Podman container | podman | local, on Linux, WSL2, or macOS with a rootless podman machine | Unconstrained | Disposable container |
| Docker container | docker | local, with a reachable Linux Docker daemon, including a VM on macOS | Unconstrained | Disposable container |
| Apple container | apple-container | local, on macOS 26+ with Apple silicon | Unconstrained | Disposable container |
| Remote checkout or isolated clone | bare | an ssh machine, a named Linux host | Guardian or unconstrained | Existing directory or independent clone on that host |
| Podman over SSH | podman | an ssh machine | Unconstrained | Disposable remote container |
| Docker over SSH | docker | an ssh machine | Unconstrained | Disposable remote container |
| AWS EC2 | bare | an aws-ec2 machine, in your AWS account | Unconstrained | Disposable instance |
“Configured approvals” means the harness profile remains in control of its approval behavior. “Unconstrained” means Mjolnir deliberately selects the harness’s full-access mode and relies on the runtime boundary to contain the blast radius. The exact controls and data boundaries are documented in Security boundaries.
Use a bare local target when you specifically want the agent to operate on your machine under its normal approvals. Use a container for a disposable full-access environment. Use SSH or EC2 when the work needs a different host, architecture, or capacity pool. Per-runtime requirements are collected in the Targets guide.
The controller, viewer, and local bare worker run on Linux and macOS. On macOS,
Podman through a rootless podman machine, Apple Container, Docker through a
Linux VM, and remote targets are also available. Native Windows is not
supported; run Mjolnir under WSL2 instead.
Where to go next
Section titled “Where to go next”- Install Mjolnir and follow the Quickstart for a first session.
- Read Terminal surface to learn the dashboard and its global keys.
- Review Security boundaries before selecting an unconstrained or remote target.
- Read Durability and recovery before relying on a session for unattended work.