Skip to main content

Command Aliases Can Now Set Your Defaults

· 2 min read
Erik Osterman
Erik Osterman
Founder @ Cloud Posse

Sometimes the built-in command defaults do not match how your team actually works. When that happens, every run starts to collect the same extra flags: disable identity for a specific workflow, auto-approve a safe apply path, or skip function processing for a common describe command.

Atmos aliases can now encode those defaults directly. They behave more like shell aliases: rewrite argv prefixes before command parsing, and match full command paths, including subcommands.

What Changed​

The aliases section is now the single interface for shortcuts and command defaults. Alias keys and values are parsed like shell fields, the longest matching command path wins, and expansion happens before flag normalization.

That means a short alias can still point at a command:

aliases:
  tp: terraform plan

And when a default flag belongs to a command or subcommand, the alias can define that too:

aliases:
  terraform: terraform --identity=false
  "terraform apply": terraform apply -auto-approve
  "describe component": describe component --process-functions=false

Running atmos terraform apply app -s dev expands the command path first, then passes the remaining arguments through normal command and flag handling.

Why It Matters​

  • One configuration surface. Aliases now cover both shortcuts and command defaults without a separate args section.
  • Subcommands work naturally. Multi-word aliases such as "terraform apply" can add behavior to one command path without affecting siblings like terraform plan.
  • User flags still win. Defaults injected by an alias appear earlier in argv, so explicit flags typed by the user later on the command line can override them.

Get Involved​

See the aliases configuration reference for examples of shortcuts, same-name aliases, command-path aliases, and quoting rules.