How the no-mistakes Repo Config Trust Boundary Prevents RCE Attacks

The no-mistakes daemon prevents remote code execution by exclusively reading shell commands and agent configurations from a freshly-fetched, pinned SHA of the default branch, ignoring any potentially malicious values pushed by contributors unless explicitly opted-in by maintainers.

The no-mistakes repository implements a strict trust boundary around the .no-mistakes.yaml configuration file to eliminate remote code execution (RCE) vulnerabilities. By treating the default branch as the sole source of truth for code-executing directives, the system ensures that malicious pull requests cannot inject dangerous commands. This design leverages Git’s object model to verify configuration integrity before any commands are executed.

How the Trust Boundary Works

The no-mistakes repo config trust boundary operates on a simple principle: never trust the pushed branch for sensitive configuration. Instead, the daemon validates all potentially dangerous settings against an immutable, maintainer-controlled commit.

Fetching the Trusted Configuration

When a run starts, the daemon creates a temporary worktree and fetches the repository’s default branch from the remote. It resolves the exact commit SHA (trustedSHA) using git.ResolveRef and reads the .no-mistakes.yaml file from that specific object via git.ShowFile. This process is orchestrated by loadTrustedRepoConfig in internal/daemon/manager.go.

If the fetch fails, the SHA cannot be resolved, or the configuration file is missing, loadTrustedRepoConfig returns nil. This triggers a fail-closed behavior where the pipeline forces Commands and Agent fields to empty values, ensuring no arbitrary code execution occurs.

The EffectiveRepoConfig Merge Logic

The EffectiveRepoConfig function in internal/config/config.go centralizes the trust decision. It accepts three parameters: the pushed configuration, the trusted configuration, and a boolean indicating whether repository commands are allowed.

When allow_repo_commands is false (the default), the function overrides the pushed branch’s Commands and Agent fields with values from the trusted copy. Non-executing settings—such as ignore patterns, auto-fix preferences, intent declarations, and test configurations—remain sourced from the pushed branch since they cannot trigger RCE.

The critical security invariant is that allow_repo_commands can only be enabled within the trusted configuration itself. A contributor cannot set this flag in their PR to bypass the trust boundary; the daemon exclusively checks this value from the default branch SHA.

Fail-Closed Behavior

The system implements defense-in-depth by defaulting to safe values. If trustedRepoCfg is nil due to any fetch or resolution error, EffectiveRepoConfig sets effective.Commands to an empty Commands{} struct and effective.Agent to an empty string. This ensures that network failures or repository corruption cannot inadvertently enable dangerous configurations.

Key Implementation Details

The trust boundary relies on three tightly-coupled components that enforce the security model at different stages of the pipeline lifecycle.

1. loadTrustedRepoConfig in internal/daemon/manager.go

This function guarantees that configuration originates from a verified, freshly-fetched default branch commit. It closes the "stale-ref" attack vector by resolving a concrete SHA rather than using a symbolic reference that could be race-conditioned.

// manager.go – startRun()
trustedSHA := ""
if repo.DefaultBranch != "" {
    if err := git.FetchRemoteBranch(ctx, wtDir, "origin", repo.DefaultBranch); err != nil {
        slog.Warn("failed to fetch default branch …")
    } else if sha, err := git.ResolveRef(ctx, wtDir,
        "refs/remotes/origin/"+repo.DefaultBranch); err != nil {
        slog.Warn("failed to resolve fetched default‑branch ref …")
    } else {
        trustedSHA = sha
    }
}

// Read .no‑mistakes.yaml from that exact SHA.
trustedRepoCfg := loadTrustedRepoConfig(ctx, wtDir, trustedSHA, run.ID)

// Decide whether to honor the contributor’s config.
allowRepoCommands := trustedRepoCfg != nil && trustedRepoCfg.AllowRepoCommands
effectiveRepoCfg := config.EffectiveRepoConfig(repoCfg, trustedRepoCfg, allowRepoCommands)

2. EffectiveRepoConfig in internal/config/config.go

This function implements the "trusted-only for code-executing fields" rule. It selectively overrides dangerous settings while preserving safe configuration from the contributor’s branch.

func EffectiveRepoConfig(pushed, trusted *RepoConfig, allowRepoCommands bool) *RepoConfig {
    if pushed == nil {
        pushed = &RepoConfig{}
    }
    effective := *pushed

    // If the maintainer has opted‑in, use the pushed config wholesale.
    if allowRepoCommands {
        return &effective
    }

    // Otherwise replace only the dangerous fields with the trusted copy.
    if trusted != nil {
        effective.Commands = trusted.Commands
        effective.Agent    = trusted.Agent
    } else {
        effective.Commands = Commands{} // empty → built‑in defaults
        effective.Agent    = ""        // empty → global default
    }
    return &effective
}

3. LoadRepoFromBytes in internal/config/config.go

This specialized loader serves as the entry point when reading from a specific Git ref. By constraining trusted config loading to this function, the codebase prevents accidental use of generic loaders that might read from the checked-out branch.

Security Test Coverage

The implementation is validated by comprehensive tests that verify the no-mistakes repo config trust boundary under various attack scenarios.

The internal/config/config_repo_trust_test.go file contains unit tests for EffectiveRepoConfig, ensuring that the trusted copy overrides only Commands and Agent while preserving other fields. The internal/e2e/repo_config_security_test.go file provides end-to-end validation that the daemon never executes commands from a malicious PR unless the maintainer has explicitly opted-in on the default branch.

These tests specifically verify that:

• Commands are not executed when the trusted config is missing or fetch fails
• The allow_repo_commands flag is only honored when set in the trusted copy
• Malicious lint commands like "rm -rf /" pushed to a feature branch are ignored

Summary

• The no-mistakes repo config trust boundary prevents RCE by sourcing shell commands exclusively from the default branch’s pinned SHA, never from the pushed branch.
• loadTrustedRepoConfig in internal/daemon/manager.go fetches and resolves the trusted configuration, returning nil on any error to trigger fail-closed behavior.
• EffectiveRepoConfig in internal/config/config.go merges configurations by overriding only the dangerous fields (Commands and Agent) with trusted values unless allow_repo_commands is enabled in the default branch config.
• The fail-closed design ensures that network failures, missing files, or resolution errors result in empty command configurations rather than potential security bypasses.
• LoadRepoFromBytes provides a safe entry point for reading configuration from specific Git refs, preventing accidental branch-based loading.

Frequently Asked Questions

What happens if the default branch fetch fails during a run?

If git.FetchRemoteBranch fails or the SHA cannot be resolved, loadTrustedRepoConfig returns nil. This causes EffectiveRepoConfig to set Commands and Agent to empty values, forcing the pipeline to use built-in defaults. The run proceeds safely without executing any repository-defined commands.

Can a contributor enable allow_repo_commands in their pull request?

No. The daemon exclusively checks the allow_repo_commands flag from the trusted configuration loaded from the default branch. Even if a contributor sets allow_repo_commands: true in their PR branch, EffectiveRepoConfig ignores this value and overrides the dangerous fields with trusted values (or empties them if the trusted config lacks these settings).

Why are non-executing settings read from the pushed branch?

Settings like ignore patterns, auto-fix preferences, and test configurations cannot trigger remote code execution. Reading these from the pushed branch allows contributors to adjust linting behavior and file exclusions without requiring maintainer approval for every change, while the trust boundary strictly isolates the Commands and Agent fields that could execute arbitrary shell code.

Which files contain the core trust boundary implementation?

The primary logic resides in internal/daemon/manager.go (orchestration and fetching), internal/config/config.go (configuration merging and loading), and internal/git/git.go (Git operations). Security tests are located in internal/config/config_repo_trust_test.go and internal/e2e/repo_config_security_test.go.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}