aws-cli-agent 0.6.0 → 0.6.2

package/CHANGELOG.md

@@ -4,6 +4,25 @@ All notable changes to this project are documented here.
 Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/);
 versioning follows [SemVer](https://semver.org/).
 
+## [0.6.2] - 2026-06-05
+
+### Changed
+
+- **README.md** Minor changes in the README.md.
+
+## [0.6.1] - 2026-05-31
+
+### Added
+
+- **AWS commands are highlighted in the bash script approval preview.** When the agent generates a script for execution, AWS CLI invocations now stand out from the rest of the script body with inverse-color "highlighter strips" so the mutating calls are easy to spot in a long script:
+  - Read-only AWS calls (`describe-*`, `list-*`, `get-*`, `s3 ls`, `sts get-caller-identity`, etc.) render as a **blue strip**.
+  - Mutating AWS calls (`delete-*`, `terminate-*`, `create-*`, `put-*`, `s3 rm`, `s3 cp`, etc.) render as a **yellow strip**.
+  - Everything else — shell control flow, comments, args, flags, pipelines — stays in the existing green script body color.
+
+  Detection is pattern-based, not a full shell parser: `aws <service> <verb>` is matched wherever it appears in a line (start of line, after a pipe, after `time` or `env VAR=val`, inside a `$(...)` substitution). Read-only vs. mutating classification uses the same `READ_ONLY_VERBS` / `READ_ONLY_FULL` lists that drive the per-command auto-approve decision — single source of truth, no drift between the two features. Adding a verb to either list affects both behaviors.
+
+  False positives (e.g. an `aws ec2 describe-instances` substring inside an `echo "..."` literal) get highlighted too. Accepted limitation: a real shell tokenizer would catch these, but the surrounding `echo` and quotes make them visually distinguishable in context.
+
 ## [0.6.0] - 2026-05-31
 
 ### Breaking
@@ -55,7 +74,6 @@ versioning follows [SemVer](https://semver.org/).
 
 - **Ctrl-C inside an SSM session no longer prints "Cannot perform start session: read /dev/stdin: input/output error".** Previously, Ctrl-C delivered SIGINT to both the AWS CLI subprocess AND aca; aca's process tore down the shared stdin before the AWS CLI's own cleanup completed, producing the I/O-error message. The fix: `aca` installs a no-op SIGINT handler for the lifetime of any interactive AWS CLI subprocess, leaving the signal exclusively to the child. The AWS CLI now performs its normal clean shutdown and exits with code 0 or 130, which aca recognizes as a clean termination.
 
-## [0.5.0] - 2026-05-19
 ### Added
 
 - **Graceful error handling for AWS CLI failures.** AWS CLI exit codes
@@ -85,8 +103,6 @@ versioning follows [SemVer](https://semver.org/).
   With verbose off, nothing aca generates reaches the terminal — only
   the AWS CLI's verbatim output does, matching the README's promise.
 
-## [0.4.0] - 2026-05-18
-
 ### Changed
 
 - **Dependency upgrades.** Vercel AI SDK v4 → v6, zod v3 → v4, TypeScript

package/README.md

@@ -1,4 +1,4 @@
-# aws-cli-agent (`aca`)
+# aws-cli-agent (aca)
 
 > Agentic AI assistant that turns natural-language requests into AWS CLI commands and runs them locally.
 
@@ -8,18 +8,20 @@ You describe what you want in plain English. The agent searches your local histo
 
 ```bash
 # Interactive session to an instance the agent has to look up
-aca "start ssm session to instance my-instance in my-account"
+aca start ssm session to instance my-instance in my-account
 
-# Use the AWS CLI's table output for human consumption
-aca "print tags of gitlab instance as table"
+# List resources
+aca list instance ids, names in my-account as text
 
-# Cross-resource composition: instances, their IAM roles, and the attached policies
-aca "list ec2 instance id, name, instance profile arn plus the iam policies in the attached iam role as json in my-account"
+# Cross-resource composition: instances, their profiles, and the attached policies
+aca list ec2 instance ids, names and the iam policies in the instance profiles as json in my-account
 ```
 
-The first example is interactive — the agent runs a read-only `describe-instances` to resolve the name, then prompts before opening the SSM session. The second produces a table on stdout, pipeable to `less` or `grep`. The third is the kind of request where the agent will most likely build a bash script with `jq` plumbing rather than chain individual AWS CLI calls.
+The first example is interactive — the agent runs a read-only `describe-instances` to resolve the name, then prompts before opening the SSM session. The second produces a text list on stdout, pipeable to `less` or `grep`. The third is the kind of request where the agent will most likely build a bash script with `jq` plumbing rather than chain individual AWS CLI calls.
 
-## ⚠️ Warning — read before using
+![aca Demo](resources/aca-demo-v0.6.1.gif)
+
+## Warning - read before using
 
 `aca` runs real AWS CLI commands against your real AWS accounts. Treat it accordingly.
 
@@ -31,15 +33,9 @@ The first example is interactive — the agent runs a read-only `describe-instan
 - **Your prompts go to the model provider.** AWS CLI output is fed back to the model as part of subsequent steps. That means resource names, instance IDs, tag values, and any other data that appears in command output is transmitted to Anthropic / OpenAI / Google / Bedrock (depending on your provider choice). The provider does not retain this data beyond the request itself (and the cache TTL, ~5 minutes for cached prefixes), but **confirm this is compatible with the policies you have to respect** before pointing `aca` at sensitive accounts.
 - **Provider terms apply.** When you use a provider, you agree to that provider's terms of service. For Bedrock, that's AWS's own terms (data stays in your AWS account boundary). For Anthropic / OpenAI / Google, that's their respective enterprise / API terms. Read them.
 - **Audit log is your friend.** Every executed command — including its stdout, stderr, and exit code — lands in `audit.log` (JSONL). If you ever need to reconstruct what happened, it's all there. Don't disable `logging.auditLog` unless you have a specific reason.
-- **API keys in the config file persist to disk.** As of 0.6.0, you can put your LLM provider API key in `<provider>.apiKey` for convenience. The env var still takes precedence when both are set. Putting a key on disk is a meaningful step down from keeping it in your shell environment: backup tools, accidental `git add .` from the wrong directory, screen-sharing, and shoulder-surfing all become realistic leak vectors. The config file is created with mode 0600 by `aca config`, but that doesn't help if you edit it with another tool that resets permissions, or if you copy your `~/.config` into a dotfiles repo. Use the env var path when possible; reserve the config-file path for casual local use.
+- **API keys in the config file persist to disk.** As of 0.6.0, you can put your LLM provider API key in `<provider>.apiKey` for convenience. The env var still takes precedence when both are set. Putting a key on disk is a meaningful step down from keeping it in your shell environment: backup tools, accidental `git add .` from the wrong directory, screen-sharing, and shoulder-surfing all become realistic leak vectors. Use the env var path when possible; reserve the config-file path for casual local use.
 - **No warranty.** **You use this agent at your own risk.** The authors are not responsible for unintended AWS API calls, deleted resources, exceeded budgets, or any other damage caused by using this tool. If you wouldn't run `aws` commands blindly from a script you found in someone's gist, don't run `aca` blindly either.
 
-## Trademark & affiliation
-
-`aws-cli-agent` (`aca`) is an independent project, not affiliated with or
-endorsed by Amazon Web Services. "AWS" and "Amazon Web Services" are
-trademarks of Amazon.com, Inc.
-
 ## Installation
 
 ```bash
@@ -67,7 +63,7 @@ export ANTHROPIC_API_KEY=sk-ant-...
 # (Bedrock needs no API key — uses your AWS credential chain)
 
 # 3. Try it
-aca "list all s3 buckets in account my-staging"
+aca list all s3 buckets in account my-staging
 ```
 
 ## Configuration
@@ -170,6 +166,26 @@ When the key is resolved from the config file instead of an env var, `aca` write
 
 The config file is created with file mode `0600` (owner read/write only) when `aca config` runs. If you edit it manually with another tool, `aca` won't re-permission it on read — that's on you.
 
+### Bedrock
+
+When `provider = "bedrock"`, configure model, region, and (optionally) profile in the `bedrock` block:
+
+```json
+{
+  "provider": "bedrock",
+  "bedrock": {
+    "model": "us.anthropic.claude-sonnet-4-6",
+    "region": "us-east-1",
+    "profile": "shared-services"
+  }
+}
+```
+
+- **Model IDs**: Bedrock uses fully-qualified inference-profile IDs. The `us.` / `eu.` / `apac.` prefix is required for most newer Anthropic models. Use `aws bedrock list-inference-profiles --region <region>` to discover what your account can invoke.
+- **`bedrock.profile`** is independent from operational profiles. The agent calls Bedrock under `bedrock.profile`, but each AWS CLI command it issues uses its own `--profile` (resolved from the user's prompt / history). This is the right pattern when one account holds Bedrock entitlements and other accounts hold workloads.
+- If `bedrock.region` is unset, falls back to `AWS_REGION` / `AWS_DEFAULT_REGION` env vars.
+- Bedrock uses the AWS credential chain — there's no `apiKey` field.
+
 ### Logging
 
 ```json
@@ -198,26 +214,6 @@ If `defaultRegion` is set, `aca` appends `--region <value>` to every AWS CLI com
 aca --region eu-west-1 "list ec2 instances in my-staging"
 ```
 
-### Bedrock
-
-When `provider = "bedrock"`, configure model, region, and (optionally) profile in the `bedrock` block:
-
-```json
-{
-  "provider": "bedrock",
-  "bedrock": {
-    "model": "us.anthropic.claude-sonnet-4-6",
-    "region": "us-east-1",
-    "profile": "shared-services"
-  }
-}
-```
-
-- **Model IDs**: Bedrock uses fully-qualified inference-profile IDs. The `us.` / `eu.` / `apac.` prefix is required for most newer Anthropic models. Use `aws bedrock list-inference-profiles --region <region>` to discover what your account can invoke.
-- **`bedrock.profile`** is independent from operational profiles. The agent calls Bedrock under `bedrock.profile`, but each AWS CLI command it issues uses its own `--profile` (resolved from the user's prompt / history). This is the right pattern when one account holds Bedrock entitlements and other accounts hold workloads.
-- If `bedrock.region` is unset, falls back to `AWS_REGION` / `AWS_DEFAULT_REGION` env vars.
-- Bedrock uses the AWS credential chain — there's no `apiKey` field.
-
 ### Prompt caching
 
 `aca` sends the same system prompt on every step of every invocation — roughly 3,300 tokens of stable content. When `caching: true` (the default), this prefix is marked cacheable on providers that support it:
@@ -415,6 +411,12 @@ aca ... 2>/dev/null                                  # silence the agent's chrom
 
 Without this rule, the approval prompts and reasoning lines would land in the next process's stdin and corrupt downstream tools. With it, the agent is invisible to pipelines — exactly as if you'd run the `aws` command directly.
 
+## Trademark & affiliation
+
+`aws-cli-agent` (`aca`) is an independent project, not affiliated with or
+endorsed by Amazon Web Services. "AWS" and "Amazon Web Services" are
+trademarks of Amazon.com, Inc.
+
 ## License
 
 MIT

package/dist/cli.js

@@ -9,7 +9,7 @@ import { History } from './history.js';
 import { runAgent } from './agent.js';
 import { FILES, PATHS, DEFAULT_SCRIPT_FOLDER } from './paths.js';
 import { UserCancelledError } from './errors.js';
-const VERSION = '0.6.0';
+const VERSION = '0.6.2';
 /**
  * Apply CLI flags on top of the loaded config. Flags only override; they
  * never widen or compose with each other implicitly.

package/dist/tools/aws-cli.d.ts

@@ -1,5 +1,20 @@
 import type { Logger } from '../logger.js';
 import type { Config } from '../config.js';
+/**
+ * Read-only verb patterns. Used both to decide whether an AWS CLI call may
+ * auto-approve, and (since 0.7.0) to syntax-highlight bash scripts in the
+ * approval display — read-only verbs render in light blue, mutating in yellow.
+ *
+ * Exported so bash.ts can apply the same classification consistently. If
+ * you add a verb here, the highlighter picks it up automatically.
+ */
+export declare const READ_ONLY_VERBS: RegExp[];
+/**
+ * Full-command patterns that are read-only but don't match a verb prefix
+ * (e.g. `s3 ls`, `sts get-caller-identity` where the resource type isn't a
+ * standard verb). Same usage as READ_ONLY_VERBS.
+ */
+export declare const READ_ONLY_FULL: RegExp[];
 export declare function awsCliTool(opts: {
     logger: Logger;
     config: Config;

package/dist/tools/aws-cli.js

@@ -4,7 +4,15 @@ import { z } from 'zod';
 import { confirm } from '@inquirer/prompts';
 import chalk from 'chalk';
 import { FATAL_AWS_EXIT_CODES, FatalAwsCliError, UserCancelledError, wrapPrompt } from '../errors.js';
-const READ_ONLY_VERBS = [
+/**
+ * Read-only verb patterns. Used both to decide whether an AWS CLI call may
+ * auto-approve, and (since 0.7.0) to syntax-highlight bash scripts in the
+ * approval display — read-only verbs render in light blue, mutating in yellow.
+ *
+ * Exported so bash.ts can apply the same classification consistently. If
+ * you add a verb here, the highlighter picks it up automatically.
+ */
+export const READ_ONLY_VERBS = [
     /^describe-/,
     /^list-/,
     /^get-/,
@@ -15,7 +23,12 @@ const READ_ONLY_VERBS = [
     /^scan$/,
     /^query$/,
 ];
-const READ_ONLY_FULL = [
+/**
+ * Full-command patterns that are read-only but don't match a verb prefix
+ * (e.g. `s3 ls`, `sts get-caller-identity` where the resource type isn't a
+ * standard verb). Same usage as READ_ONLY_VERBS.
+ */
+export const READ_ONLY_FULL = [
     /^s3\s+ls(\s|$)/,
 ];
 /**

package/dist/tools/bash.js

@@ -8,6 +8,7 @@ import { select } from '@inquirer/prompts';
 import chalk from 'chalk';
 import { DEFAULT_SCRIPT_FOLDER } from '../paths.js';
 import { wrapPrompt } from '../errors.js';
+import { READ_ONLY_FULL, READ_ONLY_VERBS } from './aws-cli.js';
 function runProcess(cmd, args) {
     return new Promise((resolve, reject) => {
         const proc = spawn(cmd, args, { env: process.env });
@@ -32,6 +33,109 @@ function indent(s, prefix) {
         .map((l) => prefix + l)
         .join('\n');
 }
+/**
+ * Match an `aws <service> <verb> ...` invocation anywhere within a line.
+ * The lookbehind is intentionally permissive — it matches `aws` at the
+ * start of the line, after a pipe (`| aws ...`), after `time aws ...`,
+ * after `env VAR=val aws ...`, etc. We don't try to be a full shell
+ * parser: that's overkill for a syntax-highlight feature. False positives
+ * (e.g. the literal string `"use aws ec2 ..."` inside an echo) get
+ * highlighted too, but that's preferable to false negatives — and the
+ * surrounding context usually makes them visually distinguishable.
+ *
+ * Captures three groups: service (group 1), verb (group 2), and the rest
+ * of the args up to end of line or a shell metacharacter that ends a
+ * command (group 3). We stop the arg span at `|`, `;`, `&`, `)`, and `>` /
+ * `<` redirections so we don't highlight half of the next pipeline stage.
+ */
+const AWS_CALL_RE = /\baws\s+([a-z][a-z0-9-]*)\s+([a-z][a-z0-9-]*)((?:\s+[^|;&)<>\n]*)?)/g;
+/**
+ * Decide whether an `aws <service> <verb>` invocation is read-only. Uses
+ * the same classification as the per-command auto-approve path so the
+ * highlighting matches the runtime behavior: if the highlight is light
+ * blue, the command would auto-approve with `autoApprove.readOnly: true`
+ * if it were a standalone tool call.
+ */
+function isAwsCallReadOnly(service, verb, restOfArgs) {
+    // READ_ONLY_FULL patterns match against `service verb [args...]`.
+    // We pass the same shape to mirror runtime behavior.
+    const full = `${service} ${verb}${restOfArgs}`;
+    if (READ_ONLY_FULL.some((re) => re.test(full)))
+        return true;
+    if (READ_ONLY_VERBS.some((re) => re.test(verb)))
+        return true;
+    return false;
+}
+/**
+ * Color the AWS CLI invocations inside a script. Read-only calls
+ * (describe-, list-, get-, etc.) render in light blue; mutating calls
+ * (delete-, terminate-, create-, etc.) render in yellow. Non-AWS portions
+ * of each line stay in the script body's default green wrap.
+ *
+ * Implementation note: chalk colors don't nest the way you'd hope. If we
+ * wrapped the whole script in `chalk.green()` and then embedded blue/yellow
+ * spans inside it, the inner spans' closing reset (\u001b[39m) would
+ * disable the green for the remainder of the string. To avoid that, we
+ * render each line piece by piece, explicitly re-applying green to the
+ * non-highlighted spans.
+ */
+function highlightAwsCalls(script) {
+    return script
+        .split('\n')
+        .map((line) => {
+        // Walk the line in pieces, emitting green for plain text and a
+        // distinct color for each AWS invocation. We use the regex's
+        // exec-loop position tracking to splice the line.
+        AWS_CALL_RE.lastIndex = 0;
+        let out = '';
+        let cursor = 0;
+        let m;
+        while ((m = AWS_CALL_RE.exec(line)) !== null) {
+            // The `aws` keyword itself isn't in the capture groups — find it
+            // by scanning backward from the service position.
+            const matchStart = m.index;
+            const service = m[1];
+            const verb = m[2];
+            const restOfArgs = m[3] ?? '';
+            const readOnly = isAwsCallReadOnly(service, verb, restOfArgs);
+            // Pre-`aws` text (e.g. `| `, `time `, or empty for start-of-line)
+            // stays green.
+            if (matchStart > cursor) {
+                out += chalk.green(line.slice(cursor, matchStart));
+            }
+            // The `aws <service> <verb>` triple gets the distinct color.
+            // restOfArgs (the flags and values) stays green — flags are the
+            // boring part, the verb is what the user needs to verify.
+            // Inverse (swaps fg/bg) produces a "highlighter strip" look: the
+            // background takes the color and the text shows through in the
+            // terminal's default foreground. Much more visible against the
+            // green script body than colored text alone would be — the eye
+            // snaps to a block of color faster than to a colored word.
+            // Green strip for read-only (matches the safe/discovery feel of
+            // the surrounding green script body); red strip for mutating
+            // (the classic "stop and look" signal).
+            const highlight = readOnly
+                ? chalk.inverse.blueBright
+                : chalk.inverse.yellowBright;
+            out += highlight(`aws ${service} ${verb}`);
+            if (restOfArgs.length > 0) {
+                out += chalk.green(restOfArgs);
+            }
+            cursor = matchStart + m[0].length;
+        }
+        // Trailing text after the last match stays green.
+        if (cursor < line.length) {
+            out += chalk.green(line.slice(cursor));
+        }
+        // If no AWS call was found in the line, fall through with the whole
+        // line in green — same as the old uniform-green behavior.
+        if (out === '') {
+            out = chalk.green(line);
+        }
+        return out;
+    })
+        .join('\n');
+}
 /**
  * Compute a filesystem-friendly filename for a saved script.
  * Combines a timestamp (so files sort chronologically) with a short slug
@@ -64,7 +168,11 @@ export function bashScriptTool(opts) {
             process.stderr.write('\n');
             process.stderr.write(`${chalk.bold('  Reason: ')}${purpose}\n`);
             process.stderr.write(`${chalk.bold('  Script:')}\n`);
-            process.stderr.write(chalk.green(indent(script, '    ')) + '\n');
+            // Render the script with AWS calls highlighted. Read-only calls
+            // (describe-, list-, get-, etc.) render in light blue; mutating calls
+            // (delete-, terminate-, create-, etc.) render in yellow. Everything
+            // else stays green. See highlightAwsCalls for the parser caveats.
+            process.stderr.write(highlightAwsCalls(indent(script, '    ')) + '\n');
             // The save-to-disk option respects the configured folder, or falls back
             // to the XDG default. Compute the would-be path *before* prompting so
             // the user can see exactly where it'll land.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aws-cli-agent",
-  "version": "0.6.0",
+  "version": "0.6.2",
   "description": "Agentic AI assistant that turns natural-language requests into AWS CLI commands and runs them locally.",
   "type": "module",
   "bin": {