Read Docker Context Details with docker context inspect

Before you run docker rm on a remote box, it pays to know which engine your CLI is really pointed at, and docker context inspect tells you. You will inspect a context, pull out the endpoint it names, and tell a missing context from an empty result.

The examples use Docker CLI 29.8.1 from the installed docker-ce-cli package version 5:29.8.1-1~ubuntu.24.04~noble. Allow about ten minutes.

1. Confirm the installed command

Check the version and the command's own option contract before relying on a script or runbook:

$ docker version --format '{{.Client.Version}}'
29.8.1
$ docker context inspect --help
Usage:  docker context inspect [OPTIONS] [CONTEXT] [CONTEXT...]

Display detailed information on one or more contexts

The only command-specific option is -f or --format. The context arguments are optional and may be repeated.

Tip: Do not confuse this with docker inspect, which examines containers, images and other Docker objects. This command examines Docker CLI contexts.

Checkpoint: If docker context inspect --help is not available, stop and check that the Docker CLI package is installed. Do not substitute a similarly named command and assume its output has the same fields.

2. See the active context's stored details

With no context argument, the installed CLI inspected the current context on this machine. Run:

$ docker context inspect

On the reference host, the result is a JSON array containing the default context:

[
    {
        "Name": "default",
        "Metadata": {},
        "Endpoints": {
            "docker": {
                "Host": "unix:///var/run/docker.sock",
                "SkipTLSVerify": false
            }
        },
        "TLSMaterial": {},
        "Storage": {
            "MetadataPath": "<IN MEMORY>",
            "TLSPath": "<IN MEMORY>"
        }
    }
]

Your output will differ. A context can contain metadata, one or more endpoint records, TLS-related material and storage paths. Read it in this order:

Security warning: Inspection can expose endpoint names, certificate paths and other operational details. Do not paste the complete output into a public issue or chat without checking it for hostnames, usernames, paths and authentication-related information.

3. Inspect a named context

Use docker context ls to get exact names, then pass one name to inspect. This first command is also read-only:

$ docker context ls
NAME        DESCRIPTION                               DOCKER ENDPOINT               ERROR
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
$ docker context inspect default

Quote names that contain shell-significant characters:

$ CONTEXT_NAME='default'
$ docker context inspect "$CONTEXT_NAME"

The name is a context identifier, not a Docker daemon hostname. To find out which context is selected before inspecting, run docker context show and compare that with the argument you intend to use.

Checkpoint: Verify the requested name rather than assuming default describes the target environment. A script that silently inspects the wrong context can produce a convincing but useless audit.

4. Extract one field with a Go template

When a script needs one stable value rather than a large JSON document, use a custom template. These fields were verified against the installed output:

$ docker context inspect --format '{{.Name}} {{.Endpoints.docker.Host}} {{.Endpoints.docker.SkipTLSVerify}}' default
default unix:///var/run/docker.sock false

The single quotes protect the template from a POSIX shell. The template walks through the top-level Name, the Docker endpoint's Host and its SkipTLSVerify value.

Warning: If a context uses a different endpoint layout, or lacks the field you request, a blank value is not proof that the endpoint is local. Inspect the full structure first.

For machine-readable output, prefer the built-in JSON format:

$ docker context inspect --format json default | jq -e '.[0] | {Name, Endpoints, Storage}'
{
  "Name": "default",
  "Endpoints": {
    "docker": {
      "Host": "unix:///var/run/docker.sock",
      "SkipTLSVerify": false
    }
  },
  "Storage": {
    "MetadataPath": "<IN MEMORY>",
    "TLSPath": "<IN MEMORY>"
  }
}

--format json keeps the result as a JSON array, so use .[0] for the first inspected context in jq. If you inspect several contexts, write the filter to process every array element rather than assuming the first record is the one you asked about.

5. Handle a missing context without guessing

A misspelled or unavailable context is an error condition. Test it without changing any Docker state:

$ docker context inspect definitely-not-a-context
[]
context "definitely-not-a-context": context not found: ...
$ printf 'exit status: %s\n' "$?"
exit status: 1

The path in the diagnostic is installation-specific and may include your home directory. The useful signals are an empty JSON array, the context not found message and a non-zero exit status. In a script, capture the status immediately:

if ! output=$(docker context inspect --format json "$CONTEXT_NAME"); then
    printf 'context inspection failed for %s\n' "$CONTEXT_NAME" >&2
    exit 1
fi
printf '%s\n' "$output"

Then compare the name against docker context ls and check whether DOCKER_CONFIG or a different user account points the CLI at another context store.

Tip: Do not create a new context merely to make an inspection command pass. Creating or changing contexts is a separate configuration task and needs its own endpoint and credential review.

6. Keep inspection separate from connection testing

docker context inspect reports context configuration. It is not a health check for the daemon. A valid-looking endpoint can still be unreachable, rejected by TLS or attached to the wrong host.

If you need to test connectivity, make that a separately approved step, using the selected context and a harmless Docker command. For example, after reviewing the endpoint and confirming the target is safe to contact, an operator might run:

$ docker --context "$CONTEXT_NAME" version --format '{{.Server.Version}}'

This can contact a remote Docker daemon and may require credentials or network access, so it is not part of the read-only inspection itself.

Warning: Do not run it against an endpoint you have not identified. No undo is needed for the inspection examples, because they alter neither the context store nor the daemon.

Done means