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

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:

• 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, 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) 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 (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:

// 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 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 (lines 16‑71), while runtime enforcement and error handling occur in internal/daemon/manager.go (lines 462‑467). Unit tests validating the boundary behavior are located in internal/config/config_repo_trust_test.go.

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