Understanding the Trust Boundary for Loading Repository Configuration in no-mistakes

The trust boundary in no-mistakes is defined by loading .no-mistakes.yaml from both the trusted default branch and the pushed contributor branch, with sensitive fields like commands and agents always sourced from the trusted copy unless the maintainer explicitly opts in via allow_repo_commands.

The no-mistakes daemon enforces a strict security model when loading repository configuration to prevent arbitrary code execution from untrusted contributor branches. Understanding the trust boundary for loading repository configuration is critical for maintainers who need to balance flexibility with security. The system reads two distinct copies of the configuration file and merges them according to hard-coded safety rules defined in the source code.

The Two Sources of Configuration

Trusted Copy from the Default Branch

The trusted copy represents the .no-mistakes.yaml file as it exists on the default branch of the remote repository, fetched at a pinned SHA. According to the source code in internal/daemon/manager.go, the function loadTrustedRepoConfig (lines 437-449) explicitly reads this file from the trusted ref:

// loadTrustedRepoConfig reads .no-mistakes.yaml from the trusted
// default‑branch copy. The daemon aborts when the trusted commit or its
// present config cannot be read and parsed.

If this file cannot be read or parsed, the daemon aborts the run entirely, ensuring that corrupted or missing trusted configuration blocks execution.

Pushed Copy from the Contributor Branch

The pushed copy contains the .no-mistakes.yaml file as it exists in the branch that the contributor has pushed (the SHA that triggered the run). This is loaded separately from the working directory checkout and represents potentially untrusted input that could attempt to inject malicious commands.

How the Trust Boundary Enforces Security

The core logic resides in EffectiveRepoConfig within internal/config/config.go (lines 41-71). This function determines which fields are taken from which copy based on the allow_repo_commands boolean flag.

Security-Critical Fields Always Sourced from Trusted Copy

When allow_repo_commands is false (the default), the following fields are hard-coded to use only the trusted copy:

• Commands (lint/test/format): Prevents contributors from injecting arbitrary shell commands
• Agent / Agents: Controls which native/ACP agent runs with maintainer credentials
• Document: Determines documentation placement policy that cannot be weakened
• DisableProjectSettings: A security boundary that cannot be toggled by contributors

Safe Fields Sourced from Pushed Copy

All other configuration fields are considered non-executing and safe to read from the contributor's branch:

• IgnorePatterns
• AutoFix
• Intent
• Test

These fields affect behavior but cannot escalate privileges or execute arbitrary code.

The Role of allow_repo_commands

The allow_repo_commands flag acts as the maintainer's opt-in mechanism for relaxing the trust boundary. When this flag is set to true in the trusted configuration, EffectiveRepoConfig returns the pushed copy fields for all settings, allowing the contributor's branch to override commands and agents.

The implementation logic from internal/config/config.go:

func EffectiveRepoConfig(pushed, trusted *RepoConfig, allowRepoCommands bool) *RepoConfig {
    // … (omitted for brevity) …
    if allowRepoCommands {
        return &effective               // use pushed fields for everything
    }
    if trusted != nil {
        effective.Commands = trusted.Commands
        effective.Agent    = trusted.Agent
        effective.Agents   = copyAgents(trusted.Agents)
    } else {
        effective.Commands = Commands{}
        effective.Agent    = ""
        effective.Agents   = nil
    }
    return &effective
}

Practical Implementation Example

When processing a run, the daemon loads both configurations and resolves the effective settings:

// Example: loading both copies inside a daemon run
trustedCfg, err := loadTrustedRepoConfig(ctx, workDir, trustedSHA, run.ID)
if err != nil {
    return err // abort if the trusted config cannot be read
}
pushedCfg, err := LoadRepo(workDir) // reads .no‑mistakes.yaml from the current checkout
if err != nil {
    return err
}

// Resolve the effective configuration
effective := EffectiveRepoConfig(pushedCfg, trustedCfg, trustedCfg.AllowRepoCommands)

When executing steps, the daemon uses the resolved configuration:

// Example: using the effective config in a step
if effective.Commands.Lint != "" {
    // safe – command came from the trusted copy (or the maintainer opted‑in)
    runLint(effective.Commands.Lint)
}

Key Files Implementing the Trust Boundary

File	Role
internal/config/config.go	Defines RepoConfig, trusted-only fields, and implements EffectiveRepoConfig.
internal/daemon/manager.go	Contains loadTrustedRepoConfig, which fetches the default-branch version of .no-mistakes.yaml.
internal/config/config_repo_trust_test.go	Test suite verifying trust-boundary behavior.
internal/daemon/manager_gate_optout_test.go	Tests loading trusted config under various scenarios.

Summary

• The trust boundary for loading repository configuration in no-mistakes relies on dual-loading .no-mistakes.yaml from both the trusted default branch and the pushed contributor branch.
• Security-sensitive fields including Commands, Agent, Agents, Document, and DisableProjectSettings always originate from the trusted copy unless allow_repo_commands is explicitly enabled.
• The EffectiveRepoConfig function in internal/config/config.go enforces this boundary by selectively merging fields based on the allow_repo_commands flag.
• Non-executing fields like IgnorePatterns and AutoFix are safely loaded from the pushed copy.
• The daemon aborts execution if the trusted configuration cannot be read or parsed, ensuring the trust boundary cannot be bypassed through missing files.

Frequently Asked Questions

What happens if the trusted .no-mistakes.yaml file is missing or corrupted?

The daemon aborts the run immediately. The loadTrustedRepoConfig function in internal/daemon/manager.go enforces that the trusted commit and its configuration must be readable and parseable; otherwise, the system refuses to proceed with execution.

Can a contributor override the linting commands by modifying .no-mistakes.yaml in their pull request?

No, unless the repository maintainer has explicitly set allow_repo_commands to true in the trusted default-branch configuration. By default, the Commands field (including lint, test, and format commands) is always sourced from the trusted copy to prevent arbitrary code injection.

How does the allow_repo_commands flag affect which agent runs the job?

When allow_repo_commands is false (default), the Agent and Agents fields are sourced exclusively from the trusted copy. This prevents contributors from selecting agents that might have elevated privileges. When set to true, the pushed copy's agent selection is honored, but this requires explicit maintainer opt-in via the trusted configuration.

Why are some configuration fields like IgnorePatterns allowed from the pushed copy while commands are not?

Fields like IgnorePatterns, AutoFix, and Intent are considered non-executing configuration—they affect how the tool behaves but cannot trigger arbitrary shell execution or credential escalation. The trust boundary specifically protects fields that could lead to code execution or security policy bypasses, while allowing flexibility for safe configuration changes.

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