[tooling] · · 2 min read
awsmux runs one AWS CLI command across hundreds of accounts in parallel — safely
A new open-source tool fans out AWS CLI commands across a fleet of accounts with STS verification, an approval gate for mutations, and built-in MCP support for AI agents.
By ByteBulletin Editor · Editor
Running the same AWS CLI command across dozens or hundreds of accounts has typically meant writing brittle shell loops, waiting ages for sequential execution, or stitching together custom orchestration. A new open-source tool called awsmux aims to fix that with a single binary that fans out commands across your entire fleet in parallel — safely.
By default, awsmux uses 100 parallel workers (configurable with --concurrency), verifies every identity with STS before running anything, and streams merged results back to the terminal. It discovers profiles from your existing ~/.aws/config and ~/.aws/credentials files, with SSO, static keys, and credential_process all working unchanged because awsmux always executes through the aws CLI.
Safety as a first-class feature
What sets awsmux apart from ad-hoc scripts is its safety model. Mutating operations are blocked by an approval boundary: the tool categorizes every AWS API call as read-only, mutating, or destructive, and anything destructive (or mutating, depending on config) returns a plan that requires manual approval via awsmux approve <plan-id>. The approval token is bound to the plan's SHA-256 hash, so tampering is refused. This even works for commands whose risk isn't obvious from their name — s3 mv is destructive because it deletes the source, and sts assume-role* is considered mutating because it mints credentials.
Stable exit codes (0 = all succeeded, 1 = some failed, 2 = config error, 3 = approval required, 4 = stopped by threshold) make it CI- and agent-friendly.
Built for AI agents
awsmux ships with a Model Context Protocol (MCP) server via awsmux mcp, giving AI agents five structured tools (list_aws_targets, plan_aws_operation, execute_aws_plan, get_aws_execution, cancel_aws_execution) instead of a raw shell. The agent uses them autonomously: ask "find every security group open to the world" and it will fan out a read-only call across all accounts, then propose a destructive fix as a plan for you to approve.
In a benchmark with 150 sessions comparing Claude Opus 4.8 agents against a raw-shell baseline across a 100-account sandbox fleet, the awsmux arm was 1.3x–2.9x cheaper, 2.3x–5.4x faster, and used up to 7.4x fewer output tokens (all Holm-adjusted p < 0.05). The tool also includes a fully local sandbox fleet (100 emulated accounts on LocalStack) for zero-risk testing.
Getting started
Prerequisites are Go, Docker, and the aws CLI. Clone the repo and run:
make build
This builds ./bin/awsmux. For the sandbox fleet:
make build fleet-up
Then point awsmux at a profile from the sandbox config. Or for real AWS, just run:
awsmux run -- ec2 describe-security-groups
For the MCP server, register with Claude Code or add to your claude_desktop_config.json:
{
"mcpServers": {
"awsmux": {
"command": "/absolute/path/to/awsmux",
"args": ["mcp"]
}
}
}
awsmux is MIT-licensed and available on GitHub.
Get the signal, not the noise.
One short email when it matters. No recaps of recaps.
SHARE
RELATED

[tooling] ·
Agentic Ship: An Open-Source Toolkit to Replace Hosted AI Builders

[tooling] ·
Goose Accelerates Release Cadence with v1.47 and v1.49 Updates

[tooling] ·
MaskShift Launches: A Zero-Dependency, Model-Agnostic Coding Harness for the Terminal

[tooling] ·
FN2 Integrates Financial Data Pipelines Directly into Claude Code

[tooling] ·
Hexis: A Git-Backed Control Plane for Managing AI Agent Skills and Permissions

[tooling] ·
