If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/munki/munki shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 2d ago
• 15 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 79% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live munki/munki repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/munki/munki.

What it runs against: a local clone of munki/munki — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in munki/munki | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of munki/munki. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/munki/munki.git
#   cd munki
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of munki/munki and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "munki/munki(\\.git)?\\b" \\
  && ok "origin remote is munki/munki" \\
  || miss "origin remote is not munki/munki (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "code/apps/Managed Software Center/Managed Software Center/AppDelegate.swift" \\
  && ok "code/apps/Managed Software Center/Managed Software Center/AppDelegate.swift" \\
  || miss "missing critical file: code/apps/Managed Software Center/Managed Software Center/AppDelegate.swift"
test -f "code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController.swift" \\
  && ok "code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController.swift" \\
  || miss "missing critical file: code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController.swift"
test -f "code/apps/Managed Software Center/Managed Software Center/MunkiItems.swift" \\
  && ok "code/apps/Managed Software Center/Managed Software Center/MunkiItems.swift" \\
  || miss "missing critical file: code/apps/Managed Software Center/Managed Software Center/MunkiItems.swift"
test -f "code/apps/Managed Software Center/Managed Software Center/MunkiURL.swift" \\
  && ok "code/apps/Managed Software Center/Managed Software Center/MunkiURL.swift" \\
  || miss "missing critical file: code/apps/Managed Software Center/Managed Software Center/MunkiURL.swift"
test -f "code/apps/Managed Software Center/Managed Software Center/FoundationPlist.swift" \\
  && ok "code/apps/Managed Software Center/Managed Software Center/FoundationPlist.swift" \\
  || miss "missing critical file: code/apps/Managed Software Center/Managed Software Center/FoundationPlist.swift"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/munki/munki"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Munki is an open-source macOS software management system that automates installation, removal, and updates of software on client machines via a centralized webserver-based repository. It handles Apple package format, drag-and-drop disk images, and Apple Software Updates, serving as the deployment backbone for organizations managing thousands of Macs. Monorepo structure with code/apps/Managed Software Center/ as the main Swift GUI application (1.5MB Swift), separate Python backend/daemon components (~992KB Python), and shell scripts for deployment (98KB Shell). The Managed Software Center XcodeProj lives at code/apps/Managed Software Center/Managed Software Center.xcodeproj/ with localization and asset catalogs, while MSCDockTilePlugin provides Objective-C integration.

macOS system administrators and IT operations teams at large organizations who need centralized, automated software deployment and lifecycle management across fleets of Macs without manual intervention.

Munki is production-ready and actively maintained. It originated at Walt Disney Animation Studios, is deployed at organizations worldwide managing tens to hundreds of thousands of Macs, and the codebase shows ongoing Swift modernization (Managed Software Center is Swift-based with active xcodeproj configuration). The presence of .travis.yml, CONTRIBUTING.md, and structured GitHub issue templates indicates mature CI/CD and community processes.

Standard open source risks apply.

The repository is actively modernizing the UI layer: Managed Software Center has been ported to Swift (most code) with SwiftFormat configuration (.swiftformat file present), and localization infrastructure is in place (Localization.swift). The dock tile plugin suggests ongoing UX refinement for user notifications.

Clone the repository with git clone https://github.com/munki/munki.git && cd munki. For the Managed Software Center app, open code/apps/Managed Software Center/Managed Software Center.xcodeproj in Xcode 12+ and build the target. For the Python daemon components, install with pip install -e . from the root (standard Python packaging expected based on structure).

Daily commands: For GUI: open code/apps/Managed Software Center/Managed Software Center.xcodeproj → Build & Run in Xcode. For daemons: python -m munki or appropriate entry point from Python package (inferred; check setup.py/pyproject.toml). For testing CLI tools: shell scripts in root or code/ subdirectories execute directly.

• code/apps/Managed Software Center/Managed Software Center/AppDelegate.swift — Entry point for the Managed Software Center macOS application; initializes the app lifecycle, window management, and core services.
• code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController.swift — Primary window controller managing the UI layout, navigation, and user interaction flow for the entire application.
• code/apps/Managed Software Center/Managed Software Center/MunkiItems.swift — Core data model representing software items, updates, and installations; essential for understanding how Munki manages software state.
• code/apps/Managed Software Center/Managed Software Center/MunkiURL.swift — URL scheme handler for inter-process communication between the GUI and Munki backend services.
• code/apps/Managed Software Center/Managed Software Center/FoundationPlist.swift — Plist serialization/deserialization utility for reading Munki configuration and metadata files from the repository.
• code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController+WKScriptMessageHandler.swift — JavaScript bridge between WebView content and native Swift code; critical for web-based UI communication.
• code/apps/Managed Software Center/Managed Software Center/HtmlFilter.swift — Sanitizes and filters HTML content for safe display in the WebView component.

Add a new dialog/alert type

1. Create a new Swift file in Controllers/ directory following MSC[FeatureName]Controller naming pattern (code/apps/Managed Software Center/Managed Software Center/Controllers/)
2. Subclass NSWindowController or NSViewController depending on modality (code/apps/Managed Software Center/Managed Software Center/Controllers/MSCAlertController.swift)
3. Define IBOutlets for UI elements and implement button actions (code/apps/Managed Software Center/Managed Software Center/Controllers/MSCPasswordAlertController.swift)
4. Call the controller from AppDelegate or MainWindowController to present modally (code/apps/Managed Software Center/Managed Software Center/AppDelegate.swift)

Add a new sidebar category or navigation item

1. Define the item type in MunkiItems.swift with Codable conformance (code/apps/Managed Software Center/Managed Software Center/MunkiItems.swift)
2. Add a new outline view delegate method in MainWindowController+NSOutlineView.swift (code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController+NSOutlineView.swift)
3. Update SidebarViewController to populate and handle the new item (code/apps/Managed Software Center/Managed Software Center/Controllers/SidebarViewController.swift)
4. Add corresponding web resources and CSS in Resources/WebResources/ if needed (code/apps/Managed Software Center/Managed Software Center/Resources/WebResources/)

Add a new JavaScript-to-Swift bridge message

1. Add a new case to the message handler in MainWindowController+WKScriptMessageHandler.swift (code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController+WKScriptMessageHandler.swift)
2. Implement the corresponding Swift handler method that processes the message (code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController.swift)
3. Add the corresponding JavaScript function in the appropriate WebResources .js file (integration.js, itemlist.js, updates.js) (code/apps/Managed Software Center/Managed Software Center/Resources/WebResources/integration.js)
4. Call webkit.messageHandlers.message.postMessage() from HTML/JavaScript to trigger the handler (code/apps/Managed Software Center/Managed Software Center/Resources/templates/apple_item_template.html)

• Swift + Cocoa (AppKit) — Native macOS development for full desktop integration, system APIs, and user experience parity with native applications
• WebKit (WKWebView) — Hybrid UI approach allowing rich HTML/CSS/JavaScript-based UI while maintaining native window chrome and accessibility
• Plist (Foundation XML format) — Standard macOS configuration format used by Munki for metadata, manifests, and software package descriptions
• URL Schemes (munki://) — Lightweight IPC mechanism between GUI and privileged backend daemons without requiring socket/RPC complexity

• Hybrid WebView + Native Swift UI (not fully native AppKit, not Electron)
  • Why: Allows rapid UI iteration with web technologies while maintaining system integration and performance; avoids Electron overhead
  • Consequence: Complexity of JavaScript-Swift bridge; must manage WebView lifecycle and security; different update cycles for web and native code

Polyglot build complexity: The project mixes Swift, Python, and Objective-C; building requires both Xcode (Swift/ObjC) and Python environments in sync. Legacy Objective-C: MSCDockTilePlugin uses older macOS APIs; sandbox/entitlements may conflict with modern security policies. Localization.swift integration: String updates must be reflected in both Swift code and any plist-based localization bundles. Repository authentication: The daemon likely requires credentials to access the webserver-based package repository; test environments need dummy repo setup. macOS version targeting: Check deployment target in .xcodeproj for OS version compatibility; recent Swift may drop support for older macOS versions.

• Package Metadata-Driven Deployment — Munki's core abstraction: software definitions live in a centralized repository as structured metadata (plist/JSON) rather than executing arbitrary scripts; this enables version tracking, dependency resolution, and rollback capabilities
• Client-Pull Repository Model — Unlike push-based systems, Munki clients poll the webserver-based repository on a schedule; reduces complexity, tolerates network interruptions, and gives users predictable update windows
• Apple Package Format (.pkg) Automation — Munki automates macOS's native package installer without wrapping or reimplementing; understanding pkgbuild, productbuild, and receipt verification is essential for troubleshooting deployments
• Dock Tile Plugin Architecture — The MSCDockTilePlugin demonstrates how macOS plugins extend app behavior without stealing window focus; critical for non-intrusive background notifications during software installation
• Manifest and Catalog Plist Structure — Munki uses plist-based manifests to define per-device software requirements and optional_installs; understanding manifest precedence and conditional installation is required for policy design
• Daemon/GUI Separation via IPC — The architecture splits privileged daemon processes from user-facing Swift GUI; understanding this boundary (likely via XPC or socket communication) is essential for debugging permission issues and adding new features

• macadmins/ubuntu-linux-for-mac — Alternative device management approach; provides context for how competitors handle similar deployment challenges
• hashicorp/packer — Complementary tool for building macOS images that Munki can then manage post-deployment
• microsoft/intune-app-sdk-ios — Microsoft's enterprise management SDK; represents competing enterprise MDM philosophy for macOS app deployment
• julianharty/ios-app-bootstrap — Shows alternative patterns for app-based package management; educational for understanding Munki's design choices
• munki/munki-pkg — Official Munki companion tool for creating macOS packages; essential for preparing software for Munki repository distribution

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for MSCStatusController.swift and core status management logic

MSCStatusController.swift is a critical UI controller that manages the application's status display, but there are no visible test files in the repository structure for Swift code. This is a high-value contribution because status management is central to Munki's user experience, and unit tests would help prevent regressions in status updates, notifications, and UI state transitions across macOS versions.

• [ ] Create code/apps/Managed Software Center/Managed Software Center.xcodeproj/Tests directory structure
• [ ] Write XCTest cases for MSCStatusController initialization, status updates, and notification handling
• [ ] Add tests for state transitions (e.g., checking → available → installing → complete)
• [ ] Verify tests run in Xcode's test runner and integrate with the .xcscheme file

Create GitHub Actions workflow for Swift code linting and building the Managed Software Center app

The repo has .travis.yml (legacy CI) but no modern GitHub Actions workflows for the Swift/Xcode components. The presence of .swiftformat in code/apps/Managed Software Center/ indicates code style standards exist but aren't enforced in CI. Adding a GitHub Actions workflow would catch build failures, formatting violations, and ensure Xcode project integrity on every PR.

• [ ] Create .github/workflows/swift-build-lint.yml that runs on push and PRs
• [ ] Add steps to validate SwiftFormat conformance against code/apps/Managed Software Center/.swiftformat config
• [ ] Add step to build the Managed Software Center.xcodeproj targeting macOS
• [ ] Include SwiftLint or equivalent static analysis if configuration exists
• [ ] Reference the existing .xcscheme in the build steps

Document the Managed Software Center Swift codebase architecture and controller responsibilities

The Controllers/ directory contains multiple specialized controllers (MSCAlertController, MSCBlockingAppsController, MSCPasswordAlertController, MSCStatusController, etc.) but there is no architecture documentation explaining their interactions, lifecycle, or responsibilities. New contributors cannot easily understand the codebase flow. Adding CONTRIBUTING.md documentation specific to the Swift app would lower the barrier to contribution.

• [ ] Create code/apps/Managed Software Center/ARCHITECTURE.md documenting the MVC/MVVM pattern used
• [ ] Document each controller's responsibility: MSCStatusController (status display), MSCBlockingAppsController (app blocking logic), MSCPasswordAlertController (authentication flows), etc.
• [ ] Include a sequence diagram or visual showing how controllers interact during software installation workflows
• [ ] Document the role of AppDelegate.swift and MainWindowController.swift in app lifecycle
• [ ] Add references to relevant configuration files (.swiftformat, project.pbxproj structure)

• Add Swift unit tests for AppDelegate.swift state transitions (app launch, window lifecycle, daemon communication); currently no Tests/ directory visible in the file list suggests test coverage gaps for the GUI layer
• Expand Localization.swift documentation and examples for translators; add missing language string keys for recent UI changes in dock tile and status window
• Refactor MSCDockTilePlugin Objective-C to modern Swift bridges using @objc and reduce code duplication with the main Swift app's notification handling

The Munki codebase appears to be a macOS management application with reasonable security posture. No critical vulnerabilities were identified from static analysis of the file structure. However, several medium-severity concerns exist primarily around HTML/content filtering, URL scheme handling, and plist processing. The application should strengthen input validation and content security policies, particularly for web content rendering and configuration file processing. Low-severity concerns include password handling in alerts and log information disclosure. The lack of visible dependency vulnerabilities file and the

• Medium · Potential XSS Risk in HTML Filtering — code/apps/Managed Software Center/Managed Software Center/HtmlFilter.swift and MSCWebView.swift. The codebase contains HtmlFilter.swift which suggests HTML content is being processed and displayed in WebView components. If the HTML filtering is not comprehensive, there could be XSS vulnerabilities when displaying user-controlled or remote content through WKWebView. Fix: Ensure HTML filtering implementation uses a whitelist approach and properly escapes/sanitizes all user-controlled input. Consider using a well-tested library like DOMPurify-equivalent for macOS. Validate that WKWebView has appropriate security policies configured (disableJavaScript if not needed, content security policies).
• Medium · URL Scheme Handler Security — code/apps/Managed Software Center/Managed Software Center/MunkiURL.swift. The MunkiURL.swift file suggests custom URL scheme handling is implemented. Custom URL schemes can be exploited if not properly validated, potentially allowing arbitrary actions to be triggered through crafted URLs. Fix: Implement strict validation of all URL scheme parameters. Use a whitelist of allowed actions and parameters. Never execute user-supplied code or commands directly from URL parameters. Log and reject suspicious URL schemes.
• Medium · Potential Insecure Plist Processing — code/apps/Managed Software Center/Managed Software Center/FoundationPlist.swift. The FoundationPlist.swift file indicates plist files are being parsed. Maliciously crafted plist files could potentially cause issues if validation is insufficient, particularly for configuration or metadata files. Fix: Implement schema validation for all plist files. Validate file sources before processing. Consider using code signing to verify repository metadata integrity. Implement proper error handling for malformed plist files.
• Medium · Missing Security Headers in Web Content — code/apps/Managed Software Center/Managed Software Center/Controllers/MainWindowController+WKNavigationDelegate.swift. The application displays web content via WKWebView. Without proper security headers and content security policies, the application may be vulnerable to content injection attacks. Fix: Configure WKWebView with appropriate security policies including Content-Security-Policy headers. Disable loading from untrusted sources. Implement certificate pinning if communicating with specific servers. Log and monitor loaded content.
• Low · Potential Information Disclosure via Logs — code/apps/Managed Software Center/Managed Software Center/Controllers/LogViewController.swift. LogViewController.swift and logging functionality could expose sensitive information if logs are not properly protected and contain details about system configuration or installed software. Fix: Implement log sanitization to remove sensitive information (paths, versions, server details). Ensure log files are stored securely with restricted permissions. Consider encrypting logs at rest. Implement log rotation and retention policies.
• Low · Password Handling in Alert Controller — code/apps/Managed Software Center/Managed Software Center/Controllers/MSCPasswordAlertController.swift. MSCPasswordAlertController.swift handles password input. If passwords are not properly cleared from memory after use or logged, this could lead to credential exposure. Fix: Ensure passwords are stored in secure memory and cleared immediately after use. Never log passwords. Use SecureTextField for password input if available. Implement timeout mechanisms for password retention in memory.
• Low · Missing Security Configuration Details — code/apps/Managed Software Center/Managed Software Center/Managed Software Center.entitlements. The entitlements file exists but specific entitlements configuration cannot be verified from the file listing alone. Overly permissive entitlements could elevate application privileges. Fix: Review entitlements file to ensure only necessary entitlements are requested. Minimize privileged access. Document why each entitlement is required. Regularly audit entitlements against principle of least privilege.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.