Skip to content

What is Mjolnir?

Mjolnir (mj) is a terminal control plane for long-lived coding-agent sessions. It starts Codex, Claude Code, Kimi Code, Grok Build, and DeepSeek Harness through the Agent Client Protocol (ACP), gives each session a durable worker, and presents all of them in one terminal dashboard and personal web viewer.

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.

A Mjolnir installation has four main parts:

  1. The controller daemon owns the local session database, provisions targets, synchronizes credentials, and serves the web viewer.
  2. A target is the place where a session runs: a local worktree, a container, a named SSH machine, or an EC2 instance.
  3. 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.
  4. 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.

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 doctor checks 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.

These are the integrations shipped with Mjolnir 2.x today:

HarnessConfig valueCredentialsQuota viewNative state in checkpointsGuardian approvals on raw targets
CodexcodexYesYesYesYes
Claude CodeclaudeYesYesYesYes
Kimi CodekimiYesYesYesNo
Grok BuildgrokYesYesYesYes
DeepSeek HarnessdeepseekYesNo subscription quotaYesNo

“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 and DeepSeek Harness do not provide a guardian approval mode. They should not be used on a raw, unsandboxed target. DeepSeek Harness currently accepts one workspace root, so use either a one-repository bundle or one bare project directory, without attached directories.

TargetConfig kindRuns onExecution policySession boundary
Local Git worktreelocal-bareLinux controller hostConfigured approvalsA Mjolnir-managed local worktree
Podman containerlocal-podmanLinux or WSL2UnconstrainedDisposable container
Docker containerlocal-dockerLinux or WSL2UnconstrainedDisposable container
Apple containerapple-containermacOS 26+ on Apple siliconUnconstrainedDisposable container
SSH machinessh-bareNamed Linux hostGuardian or unconstrainedManaged workspace on the named host
Podman over SSHssh-podmanNamed Linux hostUnconstrainedDisposable remote container
AWS EC2aws-ec2Your AWS accountUnconstrainedDisposable 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 target boundary to contain the blast radius. The exact controls and data boundaries are documented in Security boundaries.

Use a raw local worktree 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. Target-specific requirements are collected in the Targets guide.

The controller and viewer run on Linux and macOS, but current local-bare worker launch is Linux-only. On macOS, use Apple Container or a remote target for sessions. Native Windows is not supported; run Mjolnir under WSL2 instead.