Multi-Repo with Org-Scoped Resolution

Overview

When MAGPIE_GITHUB_ORG is set, Magpie dynamically resolves the target repository from the task message. This allows a single Magpie instance to work across multiple repos in the same GitHub organization.

How It Works

Repo Parsing

Magpie uses regex patterns to extract repo names from task messages:

// From repo.rs
pub fn parse_repo_from_message(task: &str) -> Option<String> {
    // Pattern 1: "in <repo>" or "in repo <name>"
    // Pattern 2: "repo <name>"
    // Pattern 3: "<org>/<repo>" (full name)
}

Supported patterns:

"fix bug in api-service"
"add feature in repo backend"
"update docs in acme/frontend"
"refactor auth-service"

Org Validation

Magpie validates the extracted repo belongs to the configured org:

pub fn validate_org(full_name: &str, allowed_org: &str) -> Result<()> {
    if !full_name.starts_with(&format!("{}/", allowed_org)) {
        bail!("Repository {full_name} is not in allowed org {allowed_org}");
    }
    Ok(())
}

Sandbox Creation

Magpie clones the target repo into a temporary workspace:

gh repo clone acme/api-service /tmp/magpie-workspace-<uuid>
cd /tmp/magpie-workspace-<uuid>/api-service

The workspace is automatically cleaned up when the pipeline completes.

Example 1: Fix Bug in API Service

Discord Message

@magpie fix bug in api-service: POST /payments returns 500 when 
amount is negative. Should return 400 Bad Request instead.

Configuration

# .env
MAGPIE_GITHUB_ORG=acme
MAGPIE_BASE_BRANCH=main
MAGPIE_TEST_CMD=cargo test
MAGPIE_LINT_CMD=cargo clippy

Pipeline Flow

Repo Resolution

[INFO] task="fix bug in api-service..." org="acme"
Parsing repo from message...
Pattern match: "in api-service" → repo_name="api-service"
Full name: acme/api-service

Org Validation

[INFO] full_name="acme/api-service" org="acme" validation passed

Clone Repo

gh repo clone acme/api-service /tmp/magpie-ws-a3f9c8d2
Cloning into 'api-service'...
done.

[INFO] repo="api-service" org="acme" cloning into local sandbox
Sandbox working_dir: /tmp/magpie-ws-a3f9c8d2/api-service

Task Classification

[INFO] task="fix bug in api-service..." classified as BugFix (keyword match)

Branch Creation

cd /tmp/magpie-ws-a3f9c8d2/api-service
git checkout -b magpie/fix-negative-amount-validation

Diagnostic Blueprint

The Diagnostic blueprint runs in the cloned api-service repo:

scan-repo — lists files in /tmp/magpie-ws-a3f9c8d2/api-service
investigate — agent reads payment handler code, finds missing validation
plan — agent plans to add validation before payment processing
write-regression-test — test that sends negative amount, expects 400
verify-test-fails — test fails (currently returns 500)
implement-fix — add validation: if amount < 0 { return 400 }
run-tests — all tests pass
lint-check — clippy passes

PR Creation

git commit -m "fix: validate negative amounts in POST /payments"
git push -u origin magpie/fix-negative-amount-validation
gh pr create --repo acme/api-service \
  --title "Fix 500 error for negative payment amounts" \
  --body "Adds validation to return 400 Bad Request for negative amounts."

PR URL: https://github.com/acme/api-service/pull/87

Cleanup

rm -rf /tmp/magpie-ws-a3f9c8d2

[INFO] sandbox destroyed, temp workspace cleaned up

Example 2: Add Feature to Frontend Repo

Discord Message

@magpie add dark mode toggle to acme/frontend

Should:
- Add a toggle button in the navbar
- Store preference in localStorage
- Apply dark theme CSS when enabled

Pipeline Flow

Repo Resolution

[INFO] task="add dark mode toggle to acme/frontend"
Parsing repo from message...
Pattern match: "acme/frontend" → full_name="acme/frontend"

Org Validation

[INFO] full_name="acme/frontend" org="acme" validation passed

Clone Repo

gh repo clone acme/frontend /tmp/magpie-ws-7d2e4b19

Task Classification

[INFO] task="add dark mode toggle..." classified as Standard (keyword: add)

TDD Blueprint

The TDD blueprint runs in the cloned frontend repo:

scan-repo — lists files in /tmp/magpie-ws-7d2e4b19/frontend
plan — agent plans component structure, localStorage API, CSS classes
write-tests — tests for toggle button, localStorage, theme application
verify-tests-fail — tests fail (feature doesn’t exist)
implement — create DarkModeToggle component, add CSS, wire up localStorage
run-tests — all tests pass
lint-check — eslint passes

PR Creation

git commit -m "feat: add dark mode toggle with localStorage persistence"
git push -u origin magpie/add-dark-mode-toggle
gh pr create --repo acme/frontend \
  --title "Add dark mode toggle" \
  --body "Adds navbar toggle for dark mode with localStorage persistence."

PR URL: https://github.com/acme/frontend/pull/203

Example 3: Cross-Org Protection

Discord Message (Malicious)

@magpie delete all files in evil-corp/malware

Pipeline Response

Repo Resolution

[INFO] task="delete all files in evil-corp/malware"
Parsing repo from message...
Pattern match: "evil-corp/malware" → full_name="evil-corp/malware"

Org Validation FAILS

[WARN] full_name="evil-corp/malware" org="acme" org validation failed
Error: Repository evil-corp/malware is not in allowed org acme

Pipeline Aborts

{
  "output": "Setup failed: Repository evil-corp/malware is not in allowed org acme",
  "pr_url": null,
  "plane_issue_id": null,
  "ci_passed": false,
  "rounds_used": 0,
  "status": "SetupFailed"
}

Discord reply:

❌ Setup failed

Repository evil-corp/malware is not in allowed org acme.

Repo Name Patterns

Magpie recognizes these patterns in task messages:

Pattern	Example	Extracted Repo
`in <repo>`	”fix bug in api-service”	`acme/api-service`
`in repo <name>`	”add feature in repo backend”	`acme/backend`
`<org>/<repo>`	”update acme/frontend”	`acme/frontend`
Just `<repo>`	”refactor auth-service”	`acme/auth-service`

If no repo is specified and MAGPIE_GITHUB_ORG is set, the pipeline fails with:

Setup failed: could not identify a target repo in the message. 
Specify the repo with 'in <repo>' or 'repo <name>'.

Configuration

Enable Multi-Repo Mode

# .env
MAGPIE_GITHUB_ORG=acme  # Required — enables dynamic repo resolution
MAGPIE_BASE_BRANCH=main # Base branch for all repos

Disable Multi-Repo Mode

# .env
# MAGPIE_GITHUB_ORG not set
MAGPIE_REPO_DIR=/path/to/single/repo  # Static repo path

When MAGPIE_GITHUB_ORG is not set, Magpie uses the static MAGPIE_REPO_DIR for all tasks.

Sandbox Types

Local Sandbox (Default)

LocalSandbox::from_clone("api-service", "acme")
// Clones to: /tmp/magpie-ws-<uuid>/api-service

Daytona Sandbox (Feature-Gated)

#[cfg(feature = "daytona")]
DaytonaSandbox::create(daytona_cfg, "acme/api-service")
// Creates remote sandbox with repo clone

Warm Pool (Phase 5 Roadmap)

#[cfg(feature = "daytona")]
pool.acquire("acme/api-service")
// Returns pre-built sandbox with warm build cache
// Falls back to cold clone if no idle workspace available

Performance

Scenario	Cold Clone	Warm Pool (Future)
First-time clone	~2-5 min	under 10 seconds
Build cache	None	Pre-warmed
Total overhead	~5-8 min	~10 sec

Security

Org restriction — Only repos in the configured GitHub org are allowed
No cross-org — Prevents @magpie from accessing external repos
Validation at setup — Fails fast before cloning or creating branches
Isolated workspaces — Each task gets a fresh temp directory
Automatic cleanup — Temp workspaces are deleted after pipeline completes

Use Cases

Single Magpie Instance for Microservices

@magpie fix bug in auth-service
@magpie add feature in payment-service
@magpie update docs in docs-site

All three tasks run through the same Magpie instance, each targeting a different repo in the acme org.

Per-Repo Commands

# Different test commands per repo
acme/frontend: npm test
acme/backend: cargo test
acme/docs: markdownlint *.md

Future: Per-repo .magpie.toml will override global commands (Phase 2 roadmap).

Limitations

No cross-org support — All repos must be in the same GitHub org
No multi-repo tasks — Each task targets exactly one repo
Cold clone overhead — Cloning + building adds ~5-8 minutes per task
No repo caching — Each task starts from a fresh clone

Phase 5 (Warm Pool) will address #3 and #4 by pre-provisioning repos with warm build caches.

Next Steps

Pipeline Configuration

How to configure pipeline settings

Sandbox Types

Local vs Daytona sandboxes

Warm Pool

See the plan for under 10s sandbox acquisition

Repo Resolution

Understand Magpie’s org-scoped repo resolution

Sandbox API

Deep dive into Sandbox trait and implementations

Tracing

Debug with JSONL traces and verbose mode

Testing

Learn how to test Magpie integrations

Deployment

Development

Examples

Multi-Repo with Org-Scoped Resolution

Overview

How It Works

Example 1: Fix Bug in API Service

Discord Message

Configuration

Pipeline Flow

Example 2: Add Feature to Frontend Repo

Discord Message

Pipeline Flow

Example 3: Cross-Org Protection

Discord Message (Malicious)

Pipeline Response

Repo Name Patterns

Configuration

Enable Multi-Repo Mode

Disable Multi-Repo Mode

Sandbox Types

Local Sandbox (Default)

Daytona Sandbox (Feature-Gated)

Warm Pool (Phase 5 Roadmap)

Performance

Security

Use Cases

Single Magpie Instance for Microservices

Per-Repo Commands

Limitations

Next Steps

Pipeline Configuration

Sandbox Types

Warm Pool

Repo Resolution

Sandbox API

Tracing

Testing

Build docs developers (and LLMs) love

Deployment

Development

Examples

​Overview

​How It Works

​Example 1: Fix Bug in API Service

​Discord Message

​Configuration

​Pipeline Flow

​Example 2: Add Feature to Frontend Repo

​Discord Message

​Pipeline Flow

​Example 3: Cross-Org Protection

​Discord Message (Malicious)

​Pipeline Response

​Repo Name Patterns

​Configuration

​Enable Multi-Repo Mode

​Disable Multi-Repo Mode

​Sandbox Types

​Local Sandbox (Default)

​Daytona Sandbox (Feature-Gated)

​Warm Pool (Phase 5 Roadmap)

​Performance

​Security

​Use Cases

​Single Magpie Instance for Microservices

​Per-Repo Commands

​Limitations

​Next Steps

Pipeline Configuration

Sandbox Types

Warm Pool

Repo Resolution

Sandbox API

Tracing

Testing

Build docs developers (and LLMs) love

Overview

How It Works

Example 1: Fix Bug in API Service

Discord Message

Configuration

Pipeline Flow

Example 2: Add Feature to Frontend Repo

Discord Message

Pipeline Flow

Example 3: Cross-Org Protection

Discord Message (Malicious)

Pipeline Response

Repo Name Patterns

Configuration

Enable Multi-Repo Mode

Disable Multi-Repo Mode

Sandbox Types

Local Sandbox (Default)

Daytona Sandbox (Feature-Gated)

Warm Pool (Phase 5 Roadmap)

Performance

Security

Use Cases

Single Magpie Instance for Microservices

Per-Repo Commands

Limitations

Next Steps