Amazon Q Developer CLI: an archived-in-place terminal agent, and what Kiro CLI replaces
✨ Agentic chat experience in your terminal. Build applications using natural language.
At a glance
- What is it?
- The repository README states the project is no longer actively maintained and receives only critical security fixes, with Kiro CLI named as the successor. This article covers what the Rust codebase actually does, how to build it locally, and why the maintenance notice should decide most adoption questions before any feature comparison does.
- Who is it for?
- Adopt this only if you need a terminal chat agent that runs against an AWS account and you accept that the README promises nothing beyond critical security fixes. Do not adopt it if you need new features, a published support path, or a roadmap, because the README directs those users to Kiro CLI.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The maintenance notice is the first thing to read
Before any discussion of features, the README carries an important block at the top: this open source project is no longer being actively maintained and will only receive critical security fixes. The same block states that Amazon Q Developer CLI is now available as Kiro CLI, described as a closed-source product, and that issues with Kiro CLI should be reported in the Kiro repository rather than here. That single paragraph changes the shape of the evaluation. You are not comparing two actively developed terminal agents. You are looking at a codebase that AWS has frozen at a maintenance floor, with the product line continuing elsewhere under a different licence model.
The last push recorded for the repository is 2026-08-24, and the most recent release listed is v1.19.7 from 2025-11-17. Those two facts sit alongside the maintenance notice without contradicting it: security fixes can still land on main while the feature surface stays fixed. Anyone reading a changelog to judge momentum should read the README notice first, because the notice is the authoritative statement about intent and the commits are not.
This is not an unusual end state for a vendor CLI that has been folded into a commercial product. It is, however, an unusual thing to find stated so plainly at the top of a README, and it deserves credit for that. Most projects in this position let the commit history do the talking.
What the q binary does and who it was built for
The project is an agentic chat experience in the terminal. The repository layout names the crate that matters: chat_cli, described as the q CLI, which lets users interface with Amazon Q Developer from the command line. Everything else in the tree is supporting infrastructure. The crates directory holds the Rust crates, scripts holds ops and build scripts, and docs holds technical documentation.
The intended user is someone who already works in a shell and wants natural language requests to turn into application changes without leaving it. The topic list on the repository includes shell, terminal, mcp, agent, and llm, which maps to that audience: developers who want an agent that can call tools, including Model Context Protocol servers, from the same window where they run builds and tests. The homepage points at an AWS documentation page for installing the command line tool, which tells you the distribution model is vendor-hosted rather than a bare cargo install from crates.io.
It is not a general-purpose chatbot wrapper. The login subcommand, visible in the contributing instructions as cargo run --bin chat_cli -- login, indicates the tool authenticates against an AWS identity before it does anything useful. If you do not have that account, the tool has no path to a working session.
Getting it running: installers for users, cargo for contributors
There are two distinct paths in the material, and they serve different people.
For users, the README lists platform installers. On macOS there is a DMG download and a Homebrew cask, brew install --cask amazon-q. On Linux the README links out to AWS documentation for Ubuntu/Debian, an AppImage, and alternative Linux builds. Those links are documentation pages, not commands reproduced in the repository, so the exact package names and repository setup steps live outside this README and should be read there rather than guessed at.
For contributors, the path is a source build. The prerequisites section names macOS with Xcode 13 or later and Brew. The clone step is git clone https://github.com/aws/amazon-q-developer-cli.git. The Rust toolchain comes from Rustup with rustup default stable and rustup toolchain install nightly, plus cargo install typos-cli for spell checking. Note that nightly is required, which is a real constraint: the formatting step is cargo +nightly fmt, so a stable-only toolchain will not run the full contributor workflow.
The day-to-day commands are short. cargo run --bin chat_cli compiles and runs the CLI. cargo test runs the suite. cargo clippy runs lints. Subcommands are passed through the same binary, so login becomes cargo run --bin chat_cli -- login. Nothing here is unusual for a Rust workspace, and the fact that the contributor path is documented at all is more than many vendor CLIs offer.
The architecture visible from the repository layout
The material supports a modest architectural claim and no more. The code is a Rust workspace: crates contains all the Rust crates, and chat_cli is the crate that produces the q binary. The topics list names TypeScript alongside Rust, so there is a non-Rust component somewhere in the tree, but the README does not describe what it does or how it connects to the CLI. Anyone who needs to know that will have to read the docs directory.
What can be said with confidence is that the CLI is the entry point and the agent loop lives behind it. The presence of mcp among the topics indicates Model Context Protocol support, which in practice means the agent can be pointed at external tool servers rather than only at built-in capabilities. The README does not document the configuration format for those servers, so the specific keys are not something this article can state.
That gap is worth naming. For a tool whose value proposition is an agent that acts on your machine, the configuration surface matters as much as the chat interface, and the README routes configuration questions to the docs directory and to AWS documentation rather than answering them inline. Treat the repository as the code and the AWS docs as the manual.
The limitation that matters most is the one in the README
The obvious failure mode is the maintenance floor. Critical security fixes only is a narrow commitment. It means a bug that is not a security issue is unlikely to be fixed, a missing feature will stay missing, and a platform change that breaks the installer may or may not be addressed depending on how it is classified. For a tool that runs an agent with access to your shell and your source tree, that classification boundary is the thing you are trusting.
The second limitation is authentication. The login subcommand ties the tool to an AWS identity. There is no described path for using it against a local model or a third-party provider, and the README does not suggest one. If your constraint is data residency, offline operation, or avoiding a vendor account, this tool is the wrong shape entirely, not merely inconvenient.
The third is the closed-source successor. The README states plainly that Kiro CLI is closed source. Teams that adopted Amazon Q Developer CLI partly because the client was open and dual licensed now face a choice between a frozen open client and a maintained closed one. That is a real fork in the road, and the README does not pretend otherwise.
What you would use instead, and how the approach differs
The alternative named by the project itself is Kiro CLI, at kiro.dev/cli. The difference in approach is not primarily technical, because the README does not enumerate feature differences. It is a difference in governance and licence. Amazon Q Developer CLI is Apache-2.0 and MIT dual licensed, with the source in this repository and a stated policy of critical security fixes only. Kiro CLI is closed source, actively developed, and takes its issues in a separate repository. If your reason for choosing the open tool was auditability of the client, Kiro CLI does not satisfy that reason, and the README is explicit about it.
A second alternative is implicit in the same notice: staying on the last release. v1.19.7 is a normal release tag, not an end-of-life marker, so the binary you install today is the binary you will have for the foreseeable future. That is acceptable for a tool you use interactively and unacceptable for one you wire into CI, because CI depends on fixes arriving.
There is no third option described in the material. The README does not point at a community fork, and this article will not invent one.
Licence and upgrade cost
The README states the repository is dual licensed under MIT and Apache 2.0, with the texts at LICENSE.MIT and LICENSE.APACHE. Dual licensing of this kind is permissive and standard for Rust tooling, and it is the reason the frozen-client problem is a governance problem rather than a legal one: you can fork, modify, and redistribute the client under those terms. What you cannot do is make AWS maintain it.
The trademark section is a separate constraint and worth reading before you build anything public on top of this. The README states that Amazon Web Services and all related marks, including logos, graphic designs, and service names, are trademarks or trade dress of AWS, and that they may not be used in connection with any product or service that is not AWS's in a manner likely to cause confusion or to disparage AWS. A fork is legally possible under the code licences; shipping that fork under an Amazon-branded name is a different question. Nothing here is legal advice, and if you plan to redistribute a modified build, the trademark paragraph is the one to put in front of a lawyer.
Upgrade cost is close to zero in one direction and unbounded in the other. There is nothing to upgrade to within this repository beyond security patches. Moving to Kiro CLI means adopting a closed-source client and a new issue tracker, which is a migration, not an upgrade.
The judgement
Use this if you want an agentic chat loop in your terminal, you already have an AWS account, and you are comfortable pinning to a release that will not gain features. The install paths are documented for macOS and Linux, the source builds with a stable-plus-nightly Rust toolchain, and the contributor workflow (cargo run --bin chat_cli, cargo test, cargo clippy, cargo +nightly fmt) is short enough to evaluate in an afternoon.
Do not use it if your adoption decision depends on a roadmap, on a support commitment beyond security fixes, or on the client being open source in the long run. The README answers all three of those questions against the project, and it does so in the first paragraph.
The thing to verify before you commit is the part the README does not cover: the actual configuration surface for MCP servers and for the agent's permissions on your machine. That lives in the docs directory and in the AWS documentation the homepage links to, not in this file. Read those pages, then decide whether a frozen client with a documented tool-calling surface is enough for the way you work.
Editorial conclusion
Adopt this only if you need a terminal chat agent that runs against an AWS account and you accept that the README promises nothing beyond critical security fixes. Do not adopt it if you need new features, a published support path, or a roadmap, because the README directs those users to Kiro CLI. Before installing anything, verify three things: the current licence files under LICENSE.MIT and LICENSE.APACHE, whether your platform is covered by the DMG, Homebrew cask, Ubuntu/Debian, or AppImage install paths, and whether the AWS account you intend to authenticate with is the one you want the agent operating against. The release cadence already answers the maintenance question: v1.19.7 landed on 2025-11-17, and the README's own notice is the only forward-looking statement the project makes.
Community notes