How no-mistakes Ensures Code-Executing Commands Originate from the Trusted Default Branch

no-mistakes guarantees that shell commands and agent configurations are always loaded from the repository's default branch by resolving the trusted commit SHA, loading the configuration exclusively from that SHA, and overriding any pushed-branch values unless the maintainer explicitly opts in via allow_repo_commands.

Supply-chain attacks in CI pipelines often exploit the gap between a contributor's feature branch and the repository's canonical state. The kunchenguid/no-mistakes daemon eliminates this attack vector by ensuring that code-executing commands—shell scripts and agent definitions—can only originate from the protected default branch, never from unreviewed pushed code.

The Security Model: Default Branch as Single Source of Truth

The architecture treats the default branch as the sole trusted authority for anything that executes code. When a run starts, the daemon does not trust the working tree checked out at the contributor's headSHA. Instead, it fetches the default branch reference, resolves its exact commit SHA, and treats that immutable reference as the only valid source for sensitive configuration fields.

This approach ensures that even if a malicious actor pushes arbitrary shell commands to their feature branch, the daemon will discard those commands and substitute values from the trusted default branch.

Step-by-Step Implementation

Resolve the Trusted Commit SHA

In internal/daemon/manager.go, the RunManager.startRun method initiates the security sequence by fetching the default branch reference. It uses git.ResolveRef to determine the exact commit SHA and stores this value in trustedSHA.

This resolution happens before any configuration parsing occurs, creating a hard boundary between the untrusted working tree and the trusted reference.

Load Configuration from the Trusted SHA

The helper function loadTrustedRepoConfig (defined in internal/daemon/manager.go lines 44–62) reads the .no-mistakes.yaml file exclusively from the trustedSHA. It does not access the working tree version.

If the SHA is empty or the file cannot be fetched, the function returns nil, triggering a fail-closed behavior where no trusted configuration exists.

Check Maintainer Opt-In

After loading the trusted configuration, the daemon reads the allow_repo_commands field (lines 74–78). This boolean is evaluated only from the trustedRepoCfg object, never from the pushed configuration.

When allowRepoCommands is false (the default), the daemon enforces that code-executing fields must come from the default branch. Maintainers must explicitly set allow_repo_commands: true in the trusted default branch to honor pushed-branch commands.

Merge with Security Override

The config.EffectiveRepoConfig function in internal/config/config.go (lines 81–94) performs the final merge. It accepts three arguments: the pushed configuration, the trusted configuration, and the allowRepoCommands boolean.

When allowRepoCommands is false, the function overrides the sensitive fields:

func EffectiveRepoConfig(pushed, trusted *RepoConfig, allowRepoCommands bool) *RepoConfig {
    if pushed == nil { pushed = &RepoConfig{} }
    effective := *pushed
    if allowRepoCommands {
        return &effective               // keep pushed commands/agent
    }
    if trusted != nil {
        effective.Commands = trusted.Commands
        effective.Agent    = trusted.Agent
    } else {
        effective.Commands = Commands{}
        effective.Agent    = ""
    }
    return &effective
}

Non-executing fields—such as ignore patterns, auto-fix settings, and test configurations—are preserved from the pushed branch unchanged, allowing contributors to modify CI behavior without compromising security.

Key Code Components

EffectiveRepoConfig Security Logic

Located in internal/config/config.go, this function is the central enforcement point. It isolates code-executing fields (Commands and Agent) from configuration fields. The logic ensures that if allowRepoCommands is false, the pushed values are discarded and replaced with trusted defaults or emptied entirely.

Trust Verification in manager.go

The internal/daemon/manager.go file orchestrates the verification sequence. It coordinates the Git reference resolution, invokes loadTrustedRepoConfig, and determines the allowRepoCommands flag. If the trusted values differ from the pushed ones, the daemon emits an informational log (lines 83–88) so maintainers can audit why feature-branch commands were ignored.

Security Testing

The behavior is validated in internal/daemon/manager_trust_test.go, which includes tests such as TestLoadTrustedRepoConfig_FailClosedOnFetchFailure to verify that the system defaults to safe values when the trusted configuration cannot be loaded.

Summary

• Immutable Reference: The daemon resolves the exact SHA of the default branch using git.ResolveRef before processing any configuration.
• Trusted-Only Loading: The loadTrustedRepoConfig function reads .no-mistakes.yaml exclusively from the trusted SHA, ignoring the working tree.
• Fail-Closed Default: Unless the maintainer explicitly sets allow_repo_commands: true in the default branch, the system overrides pushed Commands and Agent fields with trusted values.
• Clear Audit Trail: Security decisions are logged when pushed values are overridden, providing transparency for maintainers.

Frequently Asked Questions

What happens if the trusted configuration file is missing?

If .no-mistakes.yaml cannot be found at the trusted SHA or if the SHA resolution fails, loadTrustedRepoConfig returns nil. This triggers EffectiveRepoConfig to empty the Commands and Agent fields, ensuring the system fails closed rather than executing untrusted code.

Can contributors override the default branch security?

No. Contributors cannot bypass this protection from their feature branches. The allow_repo_commands flag is read only from the trusted default branch configuration. To honor pushed-branch commands, a maintainer must explicitly merge a change setting allow_repo_commands: true into the default branch.

How does no-mistakes log security decisions?

When the daemon overrides pushed values with trusted defaults, it emits an informational log entry (implemented in internal/daemon/manager.go lines 83–88). This log indicates that the pushed configuration was ignored and specifies which trusted values were substituted, providing an audit trail for maintainers.

Where is this security behavior tested?

The trust logic is comprehensively tested in internal/daemon/manager_trust_test.go. This test suite includes scenarios such as TestLoadTrustedRepoConfig_FailClosedOnFetchFailure, which verifies that the system defaults to safe, empty values when Git fetch operations fail or when the trusted reference is unavailable.

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