# Repo Config Trust Boundary Security Model in no‑mistakes: How It Prevents Supply‑Chain Attacks

> Learn how the repo config trust boundary security model in no-mistakes isolates executables to the default branch, preventing supply chain attacks and malicious code injection.

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

---

**The repo config trust boundary is a critical security mechanism that isolates executable configuration—such as shell commands and agent selections—to the repository’s default branch only, preventing malicious contributors from injecting arbitrary code via feature branches.**

The repo config trust boundary forms the defensive core of the no‑mistakes repository’s security architecture. This model establishes a strict separation between **trusted** configuration (read from the default branch) and **untrusted** configuration (read from a contributor’s pushed branch), ensuring that sensitive execution parameters remain under maintainer control exclusively.

## Why the Repo Config Trust Boundary Exists

The no‑mistakes daemon executes **commands** and selects **agents** using credentials and permissions granted to the repository maintainer. Without a trust boundary, a malicious contributor could modify `.no‑mistakes.yaml` in a feature branch to inject arbitrary shell commands or specify privileged agents. When the daemon processes the pull request, it would inadvertently execute these malicious instructions with elevated privileges.

Documentation placement rules, the `disable_project_settings` flag, and the `allow_repo_commands` opt‑in are also security‑sensitive. These settings determine what code the daemon runs and what policies it enforces. The trust boundary ensures these fields are immutable when sourced from unverified branches, effectively neutralizing supply‑chain attack vectors where contributors attempt to manipulate runtime behavior.

## How the Trust Boundary Is Implemented

### Loading Trusted vs. Untrusted Configurations

The system distinguishes between configuration sources through two distinct loading functions in [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go):

- **`LoadRepo`** reads the per‑repository `.no‑mistakes.yaml` file from a given directory path. This function processes the contributor’s working copy or pushed branch.
- **`LoadRepoFromBytes`** parses raw YAML bytes and is specifically used when reading from a specific git reference (such as the default‑branch SHA). This serves as the entry point for the trusted copy.

These functions operate at lines 79‑99 in [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go), establishing the foundation for the trust boundary by isolating how trusted and untrusted bytes enter the system.

### Merging with EffectiveRepoConfig

The `EffectiveRepoConfig` function (lines 16‑41 and 45‑71 in [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go)) implements the core security logic by merging pushed and trusted configurations according to strict rules:

- **Executable fields** (`Commands`, `Agent`, `Agents`) are **always taken from the trusted copy**. If no trusted copy exists, these fields are explicitly cleared to prevent execution of contributor‑supplied commands.
- **Documentation settings**, `disable_project_settings`, and the `allow_repo_commands` flag are sourced exclusively from the trusted default‑branch configuration.
- **Non‑executing fields** (`ignore_patterns`, `auto_fix`, `intent`, `test`) are taken from the pushed copy because they cannot trigger code execution and are safe to accept from contributors.

This selective merging ensures that the daemon never runs commands or selects agents based on unverified input.

### Runtime Enforcement in the Daemon

When a run starts, the daemon fetches both the trusted config from the default branch and the pushed config from the current branch. In [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) (lines 462‑467), failures to read or parse the trusted configuration trigger an immediate warning via `slog.Warn`, and the daemon disables command and agent execution for that specific run. This fail‑closed behavior prevents accidental execution of untrusted code when the canonical configuration is unavailable or corrupted.

### The allow_repo_commands Opt‑In

Maintainers can deliberately enable command and agent execution from pushed branches by setting `allow_repo_commands: true`. Critically, this flag must be set **in the trusted default‑branch config**; contributors cannot enable this privilege from their own branches. When this flag is absent or the trusted config is missing, the daemon forces empty command and agent fields, maintaining the security boundary even when maintainers haven’t explicitly configured opt‑in behavior.

## Security Guarantees and Field Mapping

The trust boundary provides specific guarantees for sensitive configuration fields:

| Sensitive Setting | Source of Truth | Effect if Missing or Untrusted |
|-------------------|----------------|--------------------------------|
| `commands.*` (shell commands) | Trusted default‑branch config | Disabled → no arbitrary shell execution |
| `agent` / `agents` (process selection) | Trusted default‑branch config | Disabled → only global or safe defaults used |
| `document` (documentation placement) | Trusted default‑branch config | Falls back to empty policy |
| `disable_project_settings` | Trusted default‑branch config | Enforced only from trusted copy; contributors cannot toggle |
| `allow_repo_commands` | Trusted default‑branch config | Must be explicitly set by maintainer to enable pushed‑branch commands |

## Practical Implementation Example

The following Go pattern demonstrates how the trust boundary is enforced in practice:

```go
// Load the trusted config from the default branch (ref SHA known to the daemon)
trustedCfg, err := config.LoadRepoFromBytes(trustedYAML)

// Load the contributor’s config from the branch they pushed
pushedCfg, err := config.LoadRepo(worktreePath)

// Merge according to the trust boundary rules
effective := config.EffectiveRepoConfig(pushedCfg, trustedCfg, trustedCfg.AllowRepoCommands)

```

If `trustedCfg` is nil—indicating no `.no‑mistakes.yaml` exists on the default branch—the merge operation automatically clears `Commands`, `Agent`, and `Agents`, guaranteeing that the daemon executes no untrusted code.

## Summary

- The **repo config trust boundary** restricts executable configuration to the default branch only, preventing supply‑chain attacks via malicious pull requests.
- **`LoadRepoFromBytes`** and **`LoadRepo`** provide separate entry points for trusted and untrusted configuration data.
- **`EffectiveRepoConfig`** enforces the security model by clearing executable fields when trusted configuration is unavailable.
- The **`allow_repo_commands`** flag provides an explicit opt‑in mechanism, but must be set in the trusted default‑branch configuration.
- Runtime enforcement in **[`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go)** ensures fail‑closed behavior when the trusted config cannot be read.

## Frequently Asked Questions

### What happens if the default branch lacks a .no‑mistakes.yaml file?

The daemon logs a warning using `slog.Warn` and immediately disables command and agent execution for that run. The executable fields are cleared, ensuring the system operates in a safe mode without executing any contributor‑supplied commands.

### Can contributors override the trust boundary using the allow_repo_commands setting?

No. The `allow_repo_commands` flag must be defined in the **trusted default‑branch configuration**. Contributors cannot enable command execution from their pushed branches, preventing malicious actors from bypassing the security model through configuration manipulation.

### Which configuration fields are considered safe to load from contributor branches?

Non‑executing fields including **`ignore_patterns`**, **`auto_fix`**, **`intent`**, and **`test`** are loaded from the pushed branch because they cannot execute arbitrary code or alter runtime execution parameters. These fields affect only linting behavior and test selection.

### Where is the trust boundary logic implemented in the source code?

The core merging logic resides in **[`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go)** (lines 16‑71), while runtime enforcement and error handling occur in **[`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go)** (lines 462‑467). Unit tests validating the boundary behavior are located in **[`internal/config/config_repo_trust_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config_repo_trust_test.go)**.