Skip to main content

​
Why use the CLI

The CLI runs the same agents as the web console, with one important difference: it works on the directory you started it in, on your machine. That makes it the right tool for code you’re actively editing. An agent can look at uncommitted changes, work-in-progress branches, and files that exist nowhere but your laptop — none of which a cloud sandbox can reach. See Installation to get set up.

​
Web console vs. CLI

The agents’ capabilities are the same. What differs is where they run and what they can reach.

​
Starting a session

Ask it something:
  • Find and resolve any vectors for XSRF/XSS attacks within this project.
  • Are there any exposed service endpoints in this project that shouldn’t be?
The footer shows the organization you’re connected to and the active model. Signing in happens once, on first launch — see Installation.

​
One-shot prompts

Run a single prompt and exit — useful in scripts, git hooks, and CI:
It prints the agent’s final answer and exits. Also --version.

​
Slash commands

Type / to get an autocomplete dropdown rather than memorizing them.

​
The model picker

/model opens a tabbed picker:
  • Popular — a curated shortlist. Works even if the model catalog is unreachable.
  • Browse — grouped by provider; drill into one to see its models.
  • Search — substring match across the full catalog, with pricing and context length per model.
Switching models mid-session carries your context forward via a summary, the same as the web console, and the transcript notes the switch.

​
Authoring skills and agents

The CLI is where skills are authored. It loads both skills and agents from the filesystem:
Override with AMPLIFY_SKILLS_DIR and AMPLIFY_AGENTS_DIR. Both load at startup, so restart after adding one. The loop is quick: write the file, restart, then give the agent a task that should trigger it — the agent activates a skill itself when its description matches. Files on disk are loaded only by your CLI sessions. To make a skill available to cloud runs — workflow steps, and agents that chat dispatches to run against a repository — ask the CLI, while signed in, to create it and save it to your organization; the built-in skill-creator skill handles the flow, bundling any script you point it at. See organization skills.

​
Signing in and settings

The CLI always works against your organization: detections, findings and artifacts write through to it, so work done locally shows up for your team. Your sign-in (the browser sign-in’s tokens, or an API key) lives in ~/.amplify/credentials.json and your settings in ~/.amplify/config.json.
  • console login — signs in again.
  • console logout — forgets the stored sign-in.
  • console setup — repeats the first-launch setup.
  • console config — prints the settings in effect.
If a sign-in is rejected, the CLI exits with the reason; run console login to sign in again.

​
Cancelling and exiting

Ctrl+C cancels a running turn and leaves the session open so you can redirect. Pressing it again when nothing is running exits.

​
What the CLI doesn’t do

  • No persistent chat history. Sessions aren’t saved; /clear is final and there’s no resuming a past conversation. Findings and detections do persist.
  • No input history recall. Arrow keys don’t walk previous messages.
  • No workflows. Workflows are a cloud feature — the CLI runs agents interactively, one session at a time.
  • No organization skills. The CLI can list the skills saved to your organization with list_skills, but it doesn’t load or activate them — they run in cloud runs. The CLI activates only the skill files on disk.

​
Next steps

Write a skill

The CLI is where skills are authored.

Install the CLI

Setup and signing in.