aws-cli-agent 0.6.0 → 0.6.1

package/CHANGELOG.md

@@ -4,6 +4,19 @@ 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.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 +68,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 +97,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/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.1';
 /**
  * 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.1",
   "description": "Agentic AI assistant that turns natural-language requests into AWS CLI commands and runs them locally.",
   "type": "module",
   "bin": {