Skip to main content
tally can apply fixes automatically. Fixes are designed to be:
  • Atomic — a fix applies fully or not at all.
  • Conflict-aware — overlapping edits are skipped rather than producing a corrupted file.
  • Configurable — per-rule fix modes let you control exactly which fixes run and when.

Basic usage

Apply all safe fixes:
Apply unsafe fixes too (includes AI-powered fixes when enabled):
--fix is not supported when the lint entrypoint is a Bake or Compose file. Lint the Dockerfile directly when you want tally to modify files.
Limit fixes to specific rules:
Use --fix-rule to limit the blast radius when applying fixes for the first time. Start with one rule at a time to review changes before committing.

Safe vs. unsafe fixes

The 🔧 marker in the rules reference indicates a rule has auto-fix support. Safe fixes are things like adding a missing newline, reordering instructions, or converting RUN echo to a COPY heredoc. Unsafe fixes may restructure stages or change command arguments.

Per-rule fix modes

Control when fixes are allowed per rule in .tally.toml:
Valid fix mode values:

How conflict resolution works

When two fixes would modify overlapping lines, tally skips the conflicting fix rather than applying a partial or corrupted change. The skipped fix is reported to stderr:
Fix skips are informational — linting continues and the violation is still reported so you can address it manually.

Examples of fixable rules

Rules marked 🔧 in the rules reference support auto-fix. Some notable examples:

AI AutoFix

Some fixes are too complex to implement deterministically. For those, tally supports an opt-in AI resolver via ACP (Agent Client Protocol). AI fixes are marked unsafe and require both --fix and --fix-unsafe. See the AI AutoFix (ACP) guide for setup instructions.