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/mumble-voip/mumble 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.

GO — Healthy across the board

• Last commit 1w ago
• 10 active contributors
• Distributed ownership (top contributor 40% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ 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 mumble-voip/mumble repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mumble-voip/mumble.

What it runs against: a local clone of mumble-voip/mumble — 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 mumble-voip/mumble | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 39 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mumble-voip/mumble. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mumble-voip/mumble.git
#   cd mumble
#
# 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 mumble-voip/mumble and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mumble-voip/mumble(\\.git)?\\b" \\
  && ok "origin remote is mumble-voip/mumble" \\
  || miss "origin remote is not mumble-voip/mumble (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.yml"
test -f ".ci/azure-pipelines/main-pr.yml" \\
  && ok ".ci/azure-pipelines/main-pr.yml" \\
  || miss "missing critical file: .ci/azure-pipelines/main-pr.yml"
test -f ".clang-format" \\
  && ok ".clang-format" \\
  || miss "missing critical file: .clang-format"
test -f "3rdPartyLicenses" \\
  && ok "3rdPartyLicenses" \\
  || miss "missing critical file: 3rdPartyLicenses"
test -f ".gitmodules" \\
  && ok ".gitmodules" \\
  || miss "missing critical file: .gitmodules"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 39 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~9d)"
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/mumble-voip/mumble"
  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).

Mumble is an open-source, low-latency voice-over-IP (VoIP) application written in C++ on top of Qt and Opus codec. It provides a client-server architecture where the client handles real-time audio transmission and the server (murmur) manages user authentication, channel management, and routing—solving the need for encrypted, self-hosted group voice communication without relying on commercial platforms. Monolithic application split into two main modules: src/client (Qt GUI, audio I/O, user-facing features) and src/server (murmur, daemon for channel/user management). Cross-platform audio handling is isolated in platform-specific directories (src/win32, src/posix, src/mac). Build system uses CMake (180K LOC), with CI orchestrated through .github/workflows and .ci directories. Plugins are supported via a separate plugin interface.

System administrators and communities needing self-hosted voice chat (gaming guilds, open-source teams, privacy-conscious organizations), plus C++ developers contributing to real-time audio infrastructure. Contributors typically work on cross-platform audio systems, Qt GUI development, or Opus codec integration.

Mumble is production-ready and actively maintained. The repository shows extensive CI/CD infrastructure (Azure Pipelines, Cirrus CI, GitHub Actions), comprehensive localization support (Weblate), and a mature multi-language codebase with 4.2M+ lines of C++. The presence of multiple deployment guides, plugin systems, and version-specific branches (e.g., 1.5.x) indicates stable release cycles, though the master branch contains unstable work.

Risk is moderate: the codebase has significant C++ complexity and platform-specific code (Windows, macOS, Linux, FreeBSD, OpenBSD), increasing maintenance burden. The heavy dependency on Qt and external libraries (listed in 3rdPartyLicenses/) requires careful tracking. No obvious single-maintainer risk given the organizational backing (mumble-voip team), but audio/codec changes can cause regressions.

The repository is actively developed on the master branch with unstable features. CI checks are comprehensive (build.yml, code-ql.yml for security scanning, pr-checks.yml for quality gates). Translation workflows are actively maintained (assertNoTranslationChanges.sh). The presence of release_dispatch.yml and backport.yml suggests ongoing release management across stable branches.

git clone https://github.com/mumble-voip/mumble.git
cd mumble
mkdir build && cd build
cmake ..
make
# For server (murmur), add -DBUILD_SERVER=ON to cmake

See docs/dev/build-instructions/README.md for detailed platform-specific steps. Use .github/actions/install-dependencies/main.sh for automated dependency installation.

Daily commands: After building: ./mumble (client) or ./murmur -fg (server in foreground). Server requires a database (BerkeleyDB path configured in murmur.ini). Client GUI launches immediately on supported platforms. Use ./murmur -ini murmur.ini to specify config. Development builds may require Qt plugins and audio libraries in LD_LIBRARY_PATH on Linux.

• .github/workflows/build.yml — Primary CI/CD pipeline orchestrating builds across Windows, macOS, and Linux—essential for understanding release and deployment process.
• .ci/azure-pipelines/main-pr.yml — Azure Pipelines configuration for PR validation and translation checking—critical for merge gating and code quality standards.
• .clang-format — Code style enforcement configuration used across the C++ codebase—all contributors must follow these standards.
• 3rdPartyLicenses — Centralized third-party dependency licenses and compliance documentation—legal and build integrity depends on accuracy here.
• .gitmodules — Git submodule configuration for vendored dependencies (Jack, PipeWire, GL headers)—required for correct environment setup.
• .github/pull_request_template.md — Standard PR submission template defining contribution expectations and review requirements for all pull requests.

Add Support for a New Audio Backend

1. Create new header files in 3rdparty/ for the audio API (e.g., 3rdparty/pulseaudio/pa.h) (3rdparty/)
2. Update .github/actions/install-dependencies/main.sh to bootstrap new dependencies (.github/actions/install-dependencies/main.sh)
3. Add license file to 3rdPartyLicenses/ with third-party attribution (3rdPartyLicenses/pulseaudio_license.txt)
4. Update .github/workflows/build.yml to test audio backend integration on target OS (.github/workflows/build.yml)
5. Create PR following .github/pull_request_template.md with audio subsystem changes (.github/pull_request_template.md)

Enforce a New Code Style Rule Across the Codebase

1. Add rule to .clang-format (e.g., new indentation, line length, spacing policy) (.clang-format)
2. Optionally extend .github/workflows/check_commit_style.py with custom validation (.github/workflows/check_commit_style.py)
3. Update .github/workflows/pr-checks.yml to run clang-format as a gate (.github/workflows/pr-checks.yml)
4. Document the new style rule in contributing guide and update PR template if needed (.github/pull_request_template.md)

Add Multi-Platform Build Support for New OS

1. Create install script in .github/actions/install-dependencies/ (e.g., install_freebsd_static_x86_64.sh) (.github/actions/install-dependencies/)
2. Update .github/actions/install-dependencies/main.sh to dispatch to new OS installer (.github/actions/install-dependencies/main.sh)
3. Add build matrix job to .github/workflows/build.yml targeting new OS (.github/workflows/build.yml)
4. Configure optional signing step in .github/actions/sign-binaries/ if needed for new OS (.github/actions/sign-binaries/action.yml)

• Qt & Opus — Qt provides cross-platform GUI framework (Windows/macOS/Linux); Opus is industry-standard low-latency voice codec with excellent quality
• GitHub Actions + Azure Pipelines + Cirrus CI — Multi-stage CI orchestration provides comprehensive OS coverage (Ubuntu Linux, Windows, macOS) with parallel builds and artifact management
• C++ with Clang-format — C++ delivers performance-critical real-time audio processing; clang-format ensures consistent code style across distributed contributors
• Protocol Buffers (3rdPartyLicenses reference) — Efficient binary serialization for client-server protocol definition and backward compatibility in Mumble messaging
• Jack + PipeWire + CoreAudio headers — Multiple audio backend support: Jack for professional Linux audio, PipeWire for modern Linux, CoreAudio for macOS/iOS integration

• Vendored 3rdparty headers vs. system packages

  • Why: Ensures consistent dependency versions and headers across all build environments regardless of OS package manager versions
  • Consequence: Increases repo size but reduces environment setup variance and cross-platform build failures

• Multi-platform CI (GitHub Actions + Azure + Cirrus)

  • Why: No single CI service provides equally reliable macOS, Windows, and Linux runners with artifact signing support
  • Consequence: Added complexity in maintaining multiple workflow definitions but ensures platform-specific build correctness

• Centralized 3rdPartyLicenses documentation

  • Why: Simplifies compliance auditing and legal review in one location rather than scattered LICENSE files
  • Consequence: Requires disciplined license updates during dependency upgrades

• Strict code formatting enforcement (clang-format in CI)

  • Why: Eliminates style debates in PR reviews and ensures visual consistency across ~600 files
  • Consequence: Developers must format locally before push; reduces workflow flexibility but improves code uniformity

• Does not provide web-based voice chat—client-server architecture only
• Does not handle authentication/authorization—delegates to server configuration
• Not a SaaS platform—intended for self-hosted deployment
• Does not support non-Opus audio codecs in modern versions—focuses on single high-quality codec
• Not a database system—uses SQLite for local metadata only, not distributed persistence

Platform-specific audio paths: Linux requires correct ALSA/PulseAudio/Pipewire setup; macOS needs CoreAudio permissions; Windows needs WASAPI registry tweaks. Database initialization: murmur requires BerkeleyDB to be writable in its config directory; deployment often fails silently if permissions are wrong. Qt version mismatch: CMake detects Qt5 vs Qt6; mixing versions breaks plugin loading. Translation strings: .github/workflows/assertNoTranslationChanges.sh enforces that new features include i18n; missing translations fail CI. OpenSSL 1.0 end-of-life: 3rdPartyLicenses document but code may have deprecated API usage requiring careful updates.

• Opus Audio Codec — Mumble's core for real-time voice: it provides variable bitrate, low-latency encoding essential for voice chat quality; understanding frame sizes and bitrate modes is critical for audio troubleshooting
• Protobuf Message Serialization — Mumble's client-server protocol uses Protocol Buffers for message definition and serialization; changes to Message.cpp require understanding .proto file structure
• ALSA (Advanced Linux Sound Architecture) — On Linux systems, Mumble must interact with ALSA directly or via PulseAudio/Pipewire; understanding ALSA device enumeration and PCM frames is essential for Linux audio debugging
• Qt Signal/Slot Mechanism — Mumble's entire GUI and async I/O uses Qt's signal/slot model; all UI responsiveness and inter-module communication relies on this pattern
• Cross-Platform Audio I/O Abstraction — Mumble abstracts audio input/output across 5+ OSes; understanding the platform-specific implementations (CoreAudio, WASAPI, ALSA) and their unified interface prevents platform-specific regressions
• BerkeleyDB Persistence — Murmur server uses BerkeleyDB for storing users, channels, and ACLs; understanding transaction semantics and recovery prevents data loss
• Jitter Buffer and Timestamp Synchronization — Real-time voice requires handling packet reordering and clock skew; Mumble's jitter buffer implementation ensures smooth playback despite network variance

• TeamSpeak-Systems/grift — TeamSpeak is a competing VoIP solution with similar client-server architecture; studying Mumble's design decisions helps understand VoIP trade-offs
• jitsi/jitsi-meet — WebRTC-based voice/video collaboration; represents alternative architecture (P2P, browser-first) vs. Mumble's dedicated server model
• opus-codec/opus — The upstream Opus codec library that Mumble wraps; critical for audio quality and security patches
• mumble-voip/mumble-developers — Official Mumble developer community and plugin ecosystem; plugins depend on Mumble's plugin API (src/plugins/)
• qt/qtbase — Underlying Qt framework providing GUI, networking, and cross-platform I/O; Mumble's build depends on Qt5/Qt6 version selection

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 GitHub Actions workflow for translation validation and consistency checks

The repo has .ci/azure-pipelines/assertNoTranslationChanges.sh and .ci/azure-pipelines/install-environment_linux_translations.bash but no dedicated GitHub Actions workflow. There's a .github/workflows/ directory with multiple workflows (build.yml, code-ql.yml, pr-checks.yml) but translation validation is missing. This would catch translation regressions and inconsistencies in PRs before merge, especially important for a voice chat tool supporting multiple languages.

• [ ] Create .github/workflows/translations.yml to run translation validation on PRs
• [ ] Reference and adapt logic from .ci/azure-pipelines/assertNoTranslationChanges.sh into the new workflow
• [ ] Add step to validate translation file integrity using .ci/azure-pipelines/install-environment_linux_translations.bash
• [ ] Configure workflow to run on pull_request and push to main branches
• [ ] Add notification/warning if translation files are modified without proper validation

Create comprehensive third-party license documentation in CI/documentation pipeline

The repo has extensive 3rdPartyLicenses/ directory with 30+ license files, but there's no automated CI workflow to validate that all dependencies are properly documented or that license compliance is checked. The .ci/azure-pipelines/checkDocs.bash exists but doesn't appear to validate licenses. This is critical for open-source compliance and legal requirements.

• [ ] Create .github/workflows/license-check.yml to validate license declarations on dependency updates
• [ ] Add script to parse dependency manifests (CMakeLists.txt, conanfile.txt, etc.) and cross-reference with 3rdPartyLicenses/ entries
• [ ] Implement check to ensure every external dependency has a corresponding license file
• [ ] Add step to detect new/updated dependencies in PRs and flag if license is not documented
• [ ] Reference existing license files in 3rdPartyLicenses/ directory to prevent duplicates

Add platform-specific integration tests for audio codec validation across build targets

The repo has platform-specific install scripts (.github/actions/install-dependencies/install_macos_static_x86_64.sh, install_ubuntu_static_x86_64.sh, install_windows_static_x86_64.sh) and comprehensive audio-related dependencies (libflac, libogg, libvorbis, libsndfile), but no dedicated workflow testing codec support across platforms. This would ensure audio quality consistency across Windows, macOS, and Linux builds.

• [ ] Create .github/workflows/audio-codec-tests.yml with matrix strategy for macOS, Ubuntu, and Windows
• [ ] Add integration test script that validates FLAC, Ogg Vorbis, and other codec support per platform
• [ ] Reference platform-specific dependency installation from .github/actions/install-dependencies/ directory
• [ ] Test audio encoding/decoding paths to catch platform-specific audio bugs early
• [ ] Run tests on PRs affecting audio, codec, or dependency files

• Add missing unit tests for src/Audio.cpp Opus encoding/decoding path; currently no tests cover codec state machine transitions on sample rate changes
• Extend docs/dev/plugins/README.md with a concrete C++ plugin example (e.g., a simple text-to-speech plugin); current docs only describe the interface, not scaffolding
• Audit and document platform-specific audio input device enumeration in src/win32/AudioInput.cpp, src/posix/, and src/mac/ — add parity checks and document behavior differences in a platform-compat.md file

The Mumble VoIP project demonstrates reasonable security practices with an established security.md policy and active CI/CD integration. However, several medium-severity concerns exist around third-party dependency management, potential SQL injection risks, CI/CD credential exposure, and custom cryptographic implementations. The codebase would benefit from: (1) implementing Software Composition

• Medium · Potential SQL Injection Risk in Database Layer — src/murmur/ (inferred from dependency structure). The codebase includes MariaDB C Connector and SQLite3 dependencies (evident from 3rdPartyLicenses). Without reviewing the actual source code, there is a risk of SQL injection if database queries are constructed using string concatenation or insufficient parameterization. The presence of Berkeley DB further indicates persistent data storage. Fix: Conduct a thorough code review of all database query construction. Ensure all queries use prepared statements or parameterized queries. Implement input validation and sanitization for all database operations.
• Medium · Hardcoded Security Configuration in CI/CD Pipeline — .github/workflows/ and .ci/azure-pipelines/. Multiple CI/CD configuration files (.github/workflows/, .ci/, .cirrus.yml) are present. These files may contain hardcoded credentials, API tokens, or signing keys if not properly managed. The presence of 'sign-binaries' action and release workflows increases this risk. Fix: Audit all CI/CD configuration files to ensure no hardcoded credentials or secrets are present. Use GitHub Secrets, Azure Key Vault, or equivalent secure secret management. Implement secret scanning tools in the pipeline. Rotate all potentially exposed credentials.
• Medium · Third-Party Dependency Management and Supply Chain Risk — 3rdparty/ and CMakeLists.txt (inferred). The project includes numerous third-party dependencies (OpenSSL, Protobuf, Qt, Boost, etc.) with separate license files. Without visibility into dependency pinning, version management, and vulnerability scanning, there is a supply chain risk. Outdated dependencies could contain known vulnerabilities. Fix: Implement Software Composition Analysis (SCA) tools to identify vulnerable dependencies. Use dependency lock files to pin versions. Establish a regular patching schedule for third-party components. Monitor CVE databases for dependencies, especially OpenSSL and Protobuf.
• Medium · Potential Cryptographic Implementation Risks — 3rdparty/arc4random/. The codebase includes custom cryptographic implementations (arc4random_uniform) and depends on OpenSSL. Custom crypto implementations are high-risk and may contain subtle security flaws. The arc4random implementation should be reviewed for cryptographic soundness. Fix: Conduct a security audit of custom cryptographic code by qualified cryptography experts. Consider using well-tested standard library implementations instead of custom code. Ensure OpenSSL is kept up-to-date with regular security patches.
• Low · Missing Input Validation in Build Scripts — .github/workflows/build.sh, .ci/azure-pipelines/*.bash, .ci/azure-pipelines/*.sh. Multiple shell scripts in CI/CD pipelines (.github/workflows/build.sh, .ci/azure-pipelines scripts) could be vulnerable to command injection if they accept external input without proper validation. Fix: Review all shell scripts for proper input validation. Use shellcheck tool to identify potential issues. Avoid eval() and similar dangerous constructs. Quote all variables properly to prevent word splitting and globbing attacks.
• Low · Potential XSS Risk in UI Components — src/mumble/ui/ (inferred). The project includes Qt-based UI components. If the application displays user-generated content or remote data without proper sanitization, it could be vulnerable to XSS-like attacks (Qt equivalent). Fix: Implement strict input validation and output encoding for all user-facing content. Use Qt's built-in escaping mechanisms. Perform security testing of UI components with malicious input.
• Low · Incomplete Security Policy Documentation — SECURITY.md. While a SECURITY.md file exists, it lacks detailed information about security best practices, code review processes, and responsible disclosure timeline. This could impact the effectiveness of vulnerability reporting. Fix: Expand SECURITY.md to include: expected response times, security contact details, GPG key for encrypted reports, details on patching timelines, and pre-disclosure coordination process.

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.