Skip to main content
tally supports opt-in AI AutoFix for the kinds of Dockerfile improvements that are hard to express as a purely mechanical rewrite — or too risky to apply without extra validation. Instead of asking you for an API key, tally integrates with ACP (Agent Client Protocol) — a protocol created by the Zed editor to standardize how tools talk to coding agents. This means:
  • You choose which agent you want to use (Gemini CLI, OpenCode, GitHub Copilot CLI, and more).
  • You keep credentials and model choice inside that agent.
  • tally stays a linter first — fast and deterministic — and uses AI only when you explicitly opt in.

​
How it works

tally treats AI AutoFix as a normal part of its existing fix pipeline:
  1. A rule detects a violation and attaches a SuggestedFix marked as async.
  2. tally builds a prompt containing the Dockerfile text and structured rule evidence.
  3. tally runs your configured agent via ACP over stdio.
  4. The agent returns a unified diff patch targeting the exact Dockerfile bytes from the prompt.
  5. tally validates the patch: parses it, re-lints the result, and checks invariants.
  6. If valid, the patch is applied. If not, tally skips the fix and continues linting.
Linting always works even when AI is misconfigured or unavailable.

​
Quick start

1

Pick an ACP agent

Choose an ACP-capable CLI agent. Any of these work out of the box:Browse the full registry at agentclientprotocol.com/get-started/registry.
2

Enable AI in .tally.toml

Create or update your .tally.toml. The example below uses Gemini CLI with MCP servers disabled for lower latency:
--allowed-mcp-server-names is an allowlist. Passing a name you don’t have configured (like none) effectively disables all MCP servers. tally doesn’t provide any MCP servers to the agent today, so enabling MCP is usually just extra startup and latency overhead.
3

Run an AI-powered fix

AI fixes are intentionally marked unsafe and require both --fix and --fix-unsafe. For best results, narrow the scope to a single rule:
To prevent AI fixes from running accidentally, set the rule’s fix mode to "explicit" in your config:
Dockerfiles are a mature domain that most modern models understand well. For AI fixes, you usually don’t need external tools or context servers — you want fast, predictable transformations. Recommended:
  • A fast or smaller model with solid general reasoning.
  • Disable agent-side tool integrations (MCP servers) unless you know you need them.

​
Configuration reference

​
Config file (.tally.toml)

All AI settings live under [ai]:

​
Environment variables

​
CLI flags

If your agent command needs complex quoting, prefer ai.command = ["arg1", "arg2", ...] in .tally.toml rather than --acp-command.

​
Supported ACP agents

​
Native ACP agents

​
Zed-maintained adapters

​
Rules with AI AutoFix

Today tally routes AI AutoFix to two rule objectives. Each objective owns its own prompt, validators, and acceptance criteria: Each rule emits a whole-file rewrite, so only one AI fix can land per --fix invocation. If a single Dockerfile triggers both rules, run --fix --fix-unsafe --fix-rule <rule> twice, once per rule, to compose the rewrites.

​
Security and privacy

ACP is a protocol, not a sandbox. If you run a local agent process that can access your machine, it can still do so outside of ACP. Treat the agent like any other executable you run locally.
tally adds multiple guardrails for AI fixes:
  • Explicit opt-in — AI is off unless you set ai.enabled = true.
  • Unsafe gating — AI fixes require --fix-unsafe in addition to --fix.
  • Minimal capabilities — tally advertises no filesystem and no terminal capabilities via ACP.
  • Secret redaction — prompts are best-effort redacted before being sent to the agent (controlled by ai.redact-secrets).
  • Strict output contract — the agent must return a small, targeted diff patch that applies cleanly to the exact Dockerfile bytes tally sent.
  • Validation loop — tally re-parses, re-lints, and checks runtime invariants before accepting any proposed change.

​
Troubleshooting: “Skipped N fixes”

Common reasons a fix is skipped:

​
Why ACP instead of API keys

Many tools bolt AI onto a linter by asking for an OpenAI or Anthropic API key. That approach comes with trade-offs:
  • Provider lock-in — the linter becomes a mini “AI platform” that must track models, pricing, retries, and auth.
  • Secret sprawl — API keys end up in dotfiles, CI secrets, and team docs.
  • Enterprise friction — organizations often standardize on a specific gateway, proxy, or provider policy.
  • Inconsistent experience — your editor agent knows your preferences, but your linter uses a completely different stack.
ACP inverts this: tally stays agent-agnostic, you bring your own agent and existing auth setup, and you can switch models or providers without waiting for tally to add a new integration.