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

> Learn how no-mistakes defines the trust boundary for repository configuration, securing sensitive fields by default. Understand trusted vs. pushed branches.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: deep-dive
- Published: 2026-07-13

---

**The trust boundary in no-mistakes is defined by loading [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.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`](https://github.com/kunchenguid/no-mistakes/blob/main/.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`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go), the function `loadTrustedRepoConfig` (lines 437-449) explicitly reads this file from the trusted ref:

```go
// 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`](https://github.com/kunchenguid/no-mistakes/blob/main/.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`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go):

```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:

```go
// 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:

```go
// 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`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go) | Defines `RepoConfig`, trusted-only fields, and implements `EffectiveRepoConfig`. |
| [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) | Contains `loadTrustedRepoConfig`, which fetches the default-branch version of [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml). |
| [`internal/config/config_repo_trust_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config_repo_trust_test.go) | Test suite verifying trust-boundary behavior. |
| [`internal/daemon/manager_gate_optout_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/.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`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) file is missing or corrupted?

The daemon aborts the run immediately. The `loadTrustedRepoConfig` function in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/.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.