# Trust Boundary for Repo Config in no-mistakes: Default Branch vs. Pushed SHA

> Understand the trust boundary for repo config in no-mistakes. Learn how it secures execution by trusting the default branch SHA for commands and agents, while allowing flexible merges for non-executable fields.

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

---

**The no-mistakes daemon treats the repository configuration ([`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml)) as a trusted artifact only when loaded from the default branch's pinned SHA, executing commands and selecting agents exclusively from that trusted version while allowing non-executable fields to merge from the pushed SHA.**

The no-mistakes CI system implements a strict security model that prevents supply-chain remote-code-execution (RCE) attacks by isolating executable configuration to a trusted commit. Unlike typical CI systems that might execute configuration from the tip of a feature branch, the daemon resolves the default branch to an exact SHA and treats only that version as authoritative for dangerous operations. This design ensures that malicious shell commands cannot be injected through a simple pull request that modifies the repository configuration.

## Why the Trust Boundary Exists

The trust boundary exists specifically to mitigate supply-chain RCE risks. When no-mistakes executes commands defined in `commands.test`, `commands.lint`, or `commands.format`, or selects an agent through the `agent` field, it runs arbitrary code that could compromise the build environment. If these fields were loaded from the *pushed SHA*—the tip of the branch being tested—a contributor could inject malicious shell commands into [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) and trigger immediate execution.

By restricting executable configuration to the default branch only, the repository maintainers control the trust boundary. Any changes to dangerous fields must be merged into the default branch before taking effect, preventing unilateral code execution by untrusted contributors.

## How the Trust Boundary Is Enforced

The enforcement mechanism operates through a three-phase resolution process implemented in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go). During run initialization, the daemon resolves the default branch reference, pins it to an immutable SHA, and loads the configuration from that specific commit.

### Resolving the Trusted SHA

When `startRun` initiates a new run, it fetches the default branch reference and resolves it to an exact commit hash. This pinned SHA becomes the single source of truth for trusted configuration.

```go
// In internal/daemon/manager.go (approx. line 337)
if sha, err := git.ResolveRef(ctx, wtDir, "origin/"+defaultBranch); err == nil {
    trustedSHA = sha // Pinned SHA for the entire run
}

```

If the fetch fails or the SHA cannot be resolved, `trustedSHA` remains empty. This failure state triggers a safe fallback that disables executable configuration entirely.

### Loading the Trusted Configuration

The `loadTrustedRepoConfig` function reads [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) exclusively from the pinned SHA. This function returns `nil` when no trusted SHA exists, creating a hard boundary that prevents accidental execution of untrusted config.

```go
// In internal/daemon/manager.go (approx. line 156)
func loadTrustedRepoConfig(ctx context.Context, wtDir, trustedSHA, runID string) *config.RepoConfig {
    if trustedSHA == "" {
        return nil // No trusted config → commands/agent disabled
    }
    content, err := git.ShowFile(ctx, wtDir, trustedSHA, ".no-mistakes.yaml")
    // ... YAML parsing ...
}

```

When `trustedSHA` is empty, the daemon cannot load executable configuration, effectively neutralizing any malicious commands present in the pushed SHA's version of the config file.

### Merging with EffectiveRepoConfig

The `EffectiveRepoConfig` function in [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go) implements the final enforcement layer. This function merges global defaults, repository settings, and the trusted configuration while strictly separating executable from non-executable fields.

- **Executable fields** (`commands.*`, `agent`): Sourced **only** from `trustedRepoCfg`
- **Non-executable fields** (`ignore_patterns`, `auto_fix`, `intent`): May merge from the pushed SHA's configuration

```go
// In internal/daemon/manager.go (approx. line 378)
trustedRepoCfg := loadTrustedRepoConfig(ctx, wtDir, trustedSHA, run.ID)

// Later in the run setup:
effectiveCfg := config.EffectiveRepoConfig(globalCfg, repoCfg, trustedRepoCfg)

```

If `trustedRepoCfg` is `nil` due to resolution failure, `EffectiveRepoConfig` deliberately clears the `commands` and `agent` fields from the pushed configuration, ensuring no executable code runs from untrusted sources.

## Security Documentation and Rationale

This trust boundary is documented in the project's security architecture files. According to **AGENTS.md**, the design explicitly prevents supply-chain RCE by loading "code-executing selection fields (`commands.{test,lint,format}` and `agent`) from the trusted default branch, never from the pushed SHA." The **CHANGELOG.md** entry titled "security: load repo config from default branch, not pushed SHA (supply-chain RCE)" records the introduction of this mechanism, linking to the specific commits that implemented the `loadTrustedRepoConfig` and `EffectiveRepoConfig` isolation.

## Summary

- **Trust boundary location**: Between the default branch (trusted) and pushed SHA (untrusted) for executable configuration.
- **Key enforcement files**: [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) (SHA resolution and loading) and [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go) (merging logic).
- **Critical functions**: `loadTrustedRepoConfig` isolates trusted config; `EffectiveRepoConfig` filters dangerous fields.
- **Safe fallback**: When the default branch SHA cannot be resolved, executable commands and agents are disabled entirely.
- **Flexibility preserved**: Non-executable settings like `ignore_patterns` and `auto_fix` can still be tested from feature branches.

## Frequently Asked Questions

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

If the daemon cannot fetch or resolve the default branch to a SHA, `trustedSHA` remains empty. The `loadTrustedRepoConfig` function returns `nil`, causing `EffectiveRepoConfig` to strip all `commands` and `agent` fields from the configuration. The run proceeds with non-executable settings only, preventing any code execution from the untrusted pushed SHA.

### Can I test new commands in a pull request before merging to the default branch?

No. Because commands are sourced exclusively from the default branch SHA, you cannot test new command definitions in a feature branch. You must first merge the [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) changes to the default branch, after which subsequent runs will execute the new commands. This is the fundamental security trade-off of the trust boundary.

### Are all configuration fields restricted to the default branch?

No. Only executable fields—specifically `commands.test`, `commands.lint`, `commands.format`, and `agent`—are restricted to the trusted default branch configuration. Non-executable fields such as `ignore_patterns`, `auto_fix`, and `intent` can be modified in feature branches and will be merged from the pushed SHA, allowing developers to test linting rules and ignore patterns without merging to the default branch first.

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

The primary implementation resides in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) within the `startRun` function and the `loadTrustedRepoConfig` helper. The merging logic that enforces which fields come from which source is implemented in [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go) within the `EffectiveRepoConfig` function. Documentation explaining the security rationale appears in [`AGENTS.md`](https://github.com/kunchenguid/no-mistakes/blob/main/AGENTS.md) and [`CHANGELOG.md`](https://github.com/kunchenguid/no-mistakes/blob/main/CHANGELOG.md) at the repository root.