Elasticsearch CLIElasticsearchCLI

Three credential methods are supported, and the client picks one from whichever values are present. Basic username and password, an Elasticsearch API key ID and secret, or a bearer token. Settings resolve in one order: flags, then environment variables, then the profile, then defaults. es login asks for the URL, the method, the credentials, a CA certificate and a TLS preference, tests the connection, then writes ~/.config/es-cli/config.yaml. --ca-cert takes a PEM file for a private CA and --insecure skips verification for a throwaway cluster. es config view prints the saved profile including credentials, which the documentation marks as sensitive output.

Reads take -o table, -o json or -o yaml, with structured data on stdout and verbose logs on stderr. Writes are deliberately not uniform. Some return API data and some print only a success line, so the documented advice is to confirm a write with a read when a script needs a parseable result.

Every command carries an annotation. mutates=true marks a write and interactive=true marks a prompt. --read-only, or ES_READ_ONLY=true, refuses anything marked as a write before a request leaves the process. Destructive commands prompt unless --confirm is passed, and --no-input removes prompts without approving anything, so a delete under --no-input fails rather than proceeds. --if-not-exists and --if-exists absorb the 409 and the 404 that make a rerun noisy. A test in cli-go/cmd/agent_safety_manifest_test.go walks every runnable command, hashes the list together with its annotations, and fails when that hash moves. It also fails any command whose verb reads as mutating but carries no annotation.

• Requests go straight to the REST API with no Elasticsearch SDK in between. Nothing hides a response or lags a server release. The cost is that response shapes are mine to keep current, and a major version change is my problem to check.
• No query language of my own. Query DSL bodies arrive through -f as JSON or YAML, SQL through --query or a .sql file, and bulk and multi-search take NDJSON exactly as the API does. Nothing has to be relearned. In return the CLI cannot help with a malformed query beyond repeating what the cluster said.
• search query runs a match-all when -f is omitted, and merges --size, --from and --sort into the body when it is present. This is the one I would revisit. A flag that quietly rewrites a request body makes the request harder to reason about than passing the body alone.
• --insecure exists at all. A test cluster with a self-signed certificate is a real situation, and pretending otherwise pushes people toward worse workarounds. It sits in the docs next to --ca-cert and a warning.

export ES_URL=https://elasticsearch.example.com:9200
export ES_API_KEY_ID=key-id ES_API_KEY=key-secret
es cluster health -o json | jq -r .status
es index create app-events -f settings.yaml --if-not-exists
es ilm create logs-policy -f policy.json --if-not-exists
es document bulk -f seed.ndjson --index app-events -o json
es search query app-events -f query.json --size 20 --sort timestamp:desc -o json

Each step is safe to rerun, which is the point of the idempotency flags. The same script under ES_READ_ONLY=true stops at the first create rather than completing half of the work. That is also how the Reckon workspace hands the binary to an agent: read-only, no input, pointed at log indices.

It is an independent wrapper over the Elasticsearch HTTP API and not affiliated with Elastic. Coverage stops at cluster, index, document, search, ingest, ILM, node and shard work. Snapshots, security realms and roles, watcher and machine learning are absent. SQL depends on the server license, so a command can be present and still refused upstream. es node hot-threads returns plain text whatever -o says. Building needs Go 1.26 or later, against an API baseline checked at Elasticsearch 9.5.3. It is MIT licensed and ships one binary with es update for self replacement.