mog — Sandboxed Claude Issue Mogging

One command to go from GitHub issue to pull request, powered by Claude Code running in a Docker sandbox.

mog workingdevshero/automate-it 123

That's it. mog will:

1. Fetch the issue title, description, labels, and comments via gh CLI
2. Create a git worktree on a clean branch (123-fix-broken-login)
3. Run Claude Code inside a persistent Docker sandbox (microVM) with --dangerously-skip-permissions
4. Plan — analyze the codebase and create an implementation plan
5. Build — execute each task in the plan, one at a time
6. Review — self-review all changes for missed patterns, duplication, and quality
7. Squash commits, push the branch, and open a PR that Closes #123

Prerequisites

• macOS or Windows (Docker sandbox microVMs require Docker Desktop)
• Docker Desktop 4.40+ — running and up to date. Docker sandbox support (required by mog) was introduced in Docker Desktop 4.40. Verify with docker sandbox ls.
• Bun — install from bun.sh
• GitHub CLI (gh) — authenticated via gh auth login
• Git with push access to your target repos

Install

bun install -g @bobbyg603/mog

Quick start

# 0. Verify Docker sandbox support is available
docker sandbox ls

# 1. One-time setup: create sandbox & authenticate
mog init
# This launches Claude Code — use /login to authenticate with your Max subscription
# Once logged in, type /exit to return

# 2. Start mogging issues
mog workingdevshero/automate-it 123

How authentication works

mog init creates a persistent Docker sandbox named mog. When it launches, you authenticate once using /login inside the Claude Code session. Your auth persists in the sandbox across all future mog runs — you never need to login again.

If your session ever expires, just run mog init again to re-authenticate.

Usage

# One-time setup
mog init

# Auto-detect repo from git remote (run from inside a git repo)
mog 123

# Explicit repo
mog owner/repo 123

# Include files the project needs at runtime (e.g. .env, credentials)
# Files are copied into the worktree and removed before pushing
mog 123 --include .env --include serviceAccountKey.json

# List open issues
mog list
mog list --verbose
mog owner/repo list --verbose

# Check version
mog --version
mog -v

Git identity

mog automatically configures the git identity inside the sandbox so commits are attributed correctly. Identity is resolved via a 3-tier priority chain:

1. Per-repo mog config (~/.mog/repos/<owner>/<repo>/config.json)
2. Host git config (auto-detected at runtime from your local git config)
3. Global mog config (~/.mog/config.json)

Most users need zero configuration — mog reads your host git identity automatically. Use mog config to override when needed:

# View current per-repo config (auto-detected from git remote)
mog config

# Set per-repo git identity
mog config user.name "Your Name"
mog config user.email "you@example.com"

# Set global fallback identity
mog config --global user.name "Your Name"
mog config --global user.email "you@example.com"

Re-mogging

Running mog again on an issue that already has an open PR will:

1. Fetch review comments and feedback from the existing PR
2. Include that feedback in the prompt so Claude addresses it
3. Start fresh from the default branch
4. Force-push to update the existing PR

# Re-mog after getting PR feedback — Claude sees reviewer comments
mog 123

# Start completely over, ignoring the existing PR
mog 123 --fresh

How it works

┌──────────────────────────────────────────────────────────┐
│  Host machine                                            │
│                                                          │
│  1. gh issue view #123 → fetch title, body, labels,      │
│     comments, and PR review feedback (if re-mogging)     │
│  2. git worktree add → clean branch from default branch  │
│                                                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Docker sandbox "mog" (persistent microVM)         │  │
│  │                                                    │  │
│  │  • ~/mog-repos mounted as workspace                │  │
│  │  • Auth persists across runs (login once)          │  │
│  │  • Isolated from host (own Docker daemon)          │  │
│  │  • Phase 1: Plan — analyze codebase, create plan   │  │
│  │  • Phase 2: Build — execute tasks one at a time    │  │
│  │  • Phase 3: Review — self-review for quality       │  │
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  3. Squash commits into one                              │
│  4. git push origin branch (force-push if updating PR)   │
│  5. gh pr create --body "Closes #123" (or update PR)     │
└──────────────────────────────────────────────────────────┘

Configuration

Environment variables

Environment Variable	Default	Description
MOG_REPOS_DIR	~/mog-repos	Where repos are cloned and worktrees created (also the sandbox workspace)
MOG_MAX_ITERATIONS	30	Max build loop iterations per issue
MOG_MAX_CONTINUATIONS	—	Legacy alias for MOG_MAX_ITERATIONS

Config files

mog config manages git identity settings stored in ~/.mog/:

~/.mog/
  config.json                          ← global config
  repos/
    owner/repo/config.json             ← per-repo config

Config Key	Description
user.name	Git author name for commits inside the sandbox
user.email	Git author email for commits inside the sandbox

See Git identity for details on how these are resolved.

Worktree management

mog uses bare clones and git worktrees so you can run multiple issues concurrently without conflicts:

~/mog-repos/
  owner/
    repo/                    ← bare clone (or full clone)
    repo-worktrees/
      123-fix-broken-login/  ← worktree for issue #123
      456-add-dark-mode/     ← worktree for issue #456

Clean up when done:

cd ~/mog-repos/owner/repo
git worktree remove ../repo-worktrees/123-fix-broken-login

Security notes

• Claude Code runs inside a microVM via Docker sandbox — it has its own Docker daemon and cannot access your host system, terminal, or files outside ~/mog-repos.
• --dangerously-skip-permissions is safe here because the sandbox provides the isolation boundary.
• gh credentials stay on your host — the sandbox has no access to your GitHub token. Pushing and PR creation happen on the host after Claude finishes.
• The sandbox has network access (required for the Anthropic API).

Troubleshooting

"Docker sandbox not available" — Make sure Docker Desktop is running and up to date.

"Sandbox 'mog' not found" — Run mog init first to create the sandbox and authenticate.

"Failed to fetch issue" — Check gh auth status and verify the repo/issue exist.

"No changes detected" — Claude may have struggled with the issue. Check the worktree manually, or re-run with a more detailed issue description.

"Docker sandbox state is stale" — Restart Docker Desktop, or remove and recreate the sandbox: docker sandbox rm mog && mog init.

"docker: 'sandbox' is not a docker command" — Your Docker Desktop version doesn't support sandboxes. Update Docker Desktop to 4.40 or later, then verify with docker sandbox ls.

"Failed to push" — Ensure gh is authenticated with push access. Try gh auth login and select HTTPS.

Managing the sandbox

# List sandboxes
docker sandbox ls

# Stop the sandbox (preserves auth)
docker sandbox stop mog

# Remove and recreate (you'll need to /login again)
docker sandbox rm mog
mog init