# Understanding the Trust Boundary Model for Loading Repository Config Fields in no-mistakes

> Learn how the no-mistakes trust boundary model loads repository config fields safely from the default branch, preventing malicious pull request settings.

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

---

**The no-mistakes engine enforces a fail-closed trust boundary by loading executable configuration exclusively from the repository's default branch, ignoring potentially malicious settings in contributor pull requests unless explicitly authorized.**

The `no-mistakes` repository defines per-project behavior through [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) files, but executing arbitrary commands from untrusted sources creates a critical attack surface. To mitigate this, the engine implements a strict trust boundary model for loading repository config fields that guarantees only default-branch versions can influence code execution.

## Trusted Default-Branch Configuration

The foundation of the security model rests on the **trusted repo config**—a version of [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) read exclusively from the repository's default branch. According to the source code in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go), the daemon fetches this file from the default branch reference, never from the SHA of a pushed branch or pull request.

This design ensures that a contributor cannot elevate privileges by pushing a modified configuration file. When the daemon initializes, it attempts to load this trusted copy via `config.LoadRepoFromDefaultBranch`. If parsing fails or the file is missing, the system logs a warning and substitutes an empty configuration, effectively disabling all command execution for that run.

## Effective Repository Configuration and Merge Logic

The function `EffectiveRepoConfig` in [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go) orchestrates the merge strategy that enforces the trust boundary. The merge follows a strict hierarchy: **global configuration** (`~/.no-mistakes/config.yaml`) → **trusted repo configuration** (default branch) → **pushed branch configuration** (limited to non-executable fields).

Critical executable fields—including `commands.{test,lint,format}` and `agent`—are only populated from the pushed branch if the `allow_repo_commands` boolean is explicitly set to `true` in the trusted default-branch copy. By default, this value is `false`, creating an opt-in security model.

### The allow_repo_commands Gate

The `allow_repo_commands` field serves as the primary security gate. When `false` (the default), the engine processes only documentation and ignore patterns from the contributor's push, while sourcing all executable instructions from the default branch. This prevents attackers from modifying CI commands to exfiltrate secrets or compromise the build environment.

### Failure-Closed Design

The implementation adopts a **fail-closed** posture. If `LoadRepoFromDefaultBranch` returns an error—whether from network failures, YAML parsing errors, or missing files—the daemon catches this in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) and proceeds with an empty `RepoConfig` struct. This empties the `Commands` and `Agent` fields, ensuring that any configuration anomaly results in disabled execution rather than undefined behavior.

## Implementation Examples

The following Go code illustrates how the engine loads configuration while respecting the trust boundary:

```go
func LoadEffectiveConfig(ctx context.Context, repoRoot string) (*config.Config, error) {
    // Load global config (~/.no-mistakes/config.yaml)
    global, err := config.LoadGlobal()
    if err != nil { return nil, err }

    // Load trusted repo config from default branch only
    trustedRepo, err := config.LoadRepoFromDefaultBranch(ctx, repoRoot)
    if err != nil {
        slog.Warn("trusted repo config parse failed; commands/agent disabled", "err", err)
        trustedRepo = &config.RepoConfig{} // Empty config disables execution
    }

    // Merge with global settings
    cfg := config.Merge(global, trustedRepo)
    return cfg, nil
}

```

When executing pipeline steps, the engine verifies that commands originate from the trusted boundary:

```go
func runLintStep(cfg *config.Config, workdir string) error {
    // cfg.Commands.Lint is only populated when allow_repo_commands 
    // is true in the trusted default-branch config
    if cfg.Commands.Lint == "" {
        return fmt.Errorf("lint command disabled: not trusted")
    }
    return exec.CommandContext(ctx, "sh", "-c", cfg.Commands.Lint).Run()
}

```

## Summary

- The **trusted default-branch copy** of [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) serves as the sole source of truth for executable configuration.
- The `EffectiveRepoConfig` function in [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go) merges global settings with trusted repository settings, optionally incorporating non-executable fields from pushed branches.
- The **`allow_repo_commands`** boolean acts as a security gate; when `false` (default), commands and agent settings from pull requests are ignored.
- **Failure-closed design** ensures that any error loading the trusted configuration results in an empty, safe configuration that disables code execution.
- This model prevents contributors from executing arbitrary code through malicious configuration changes.

## Frequently Asked Questions

### How does no-mistakes prevent malicious commands in pull request configurations?

The engine loads the [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) file from the repository's default branch to determine which commands are permitted. Even if a contributor modifies the configuration file in their pull request, those changes are not trusted for execution unless the default-branch version explicitly sets `allow_repo_commands: true`. This ensures that only repository maintainers can authorize new commands through the protected default branch.

### What happens if the default branch configuration file is corrupted?

If `LoadRepoFromDefaultBranch` encounters a parsing error or the file is missing, the daemon logs a warning and falls back to an empty `RepoConfig` struct. This fail-closed behavior disables all `commands`, `agent`, and other executable fields for that run, preventing the engine from accidentally executing undefined or unsafe instructions.

### Which configuration fields are subject to the trust boundary?

The fields guarded by the trust boundary include `commands.test`, `commands.lint`, `commands.format`, and `agent`—any setting that could trigger code execution. Non-executable fields like `ignore_patterns` may be read from the pushed branch for convenience, while `document.instructions` and the `allow_repo_commands` flag itself are always read exclusively from the trusted default-branch copy.

### Where is the trust boundary logic tested?

The repository includes comprehensive validation in [`internal/config/config_repo_trust_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config_repo_trust_test.go) and end-to-end coverage in [`internal/e2e/harness.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/e2e/harness.go). These test suites verify that the `EffectiveRepoConfig` function correctly isolates executable fields and that the daemon exhibits fail-closed behavior when trusted configuration loading fails.