Open a new terminal in a running container

Use docker exec -it CONTAINER /bin/sh to start a new interactive shell in a running container. If the image contains Bash, you can choose /bin/bash instead. This creates another process; it does not reconnect to the main application's input stream.

docker exec -it myapp /bin/sh

-i keeps standard input open and -t allocates a pseudo-terminal. The shell provides its own prompt, completion, and other interactive features; allocating a TTY does not install those features or guarantee a particular prompt.

Select the user and location

docker exec -u www-data -w /app -it myapp /bin/sh

The named user and directory must exist in the container. If an authorized diagnostic task genuinely needs container-root access, -u 0 selects UID 0. It does not bypass a read-only mount, every security policy, or user-namespace mapping.

For one noninteractive command, omit the TTY:

docker exec myapp cat /etc/app/config.yml

Avoid displaying secrets from configuration files. For a pipeline supplying input, use -i only when needed; -t can fail in CI with “the input device is not a TTY” or alter stream behavior.

Check that a shell actually exists

Alpine commonly includes /bin/sh; a particular Ubuntu or Debian-derived image is not guaranteed to retain Bash. Distroless and scratch-based images may contain no shell at all. In that case, use available inspection mechanisms:

docker cp myapp:/app/logs ./logs
docker diff myapp
docker logs --tail 100 myapp

Installing tools requires the image's package manager, suitable permissions, and network access, and changes the running container. A separate debug image or supported debug workflow is often more reproducible. Kubernetes ephemeral containers provide another diagnostic process, but do not automatically share the target container's root filesystem.

Understand the session's limits

Exiting the exec shell normally leaves the container's main process running. However, the session shares relevant container resources: editing configuration, deleting files, or sending signals can affect the application. Several exec sessions can run simultaneously, but they can race over the same files and processes.

An exec process only runs while the container's main process is running. It is not automatically recreated when the container restarts. Docker initializes its environment from the container's creation settings, with optional -e overrides, rather than reading every later export from PID 1.

FAQ

What if the container is stopped or paused?

Inspect its state and logs first. Exec requires a running, unpaused container. Starting or unpausing a production service can have application effects; use copy or other offline inspection when restarting it is not the right action.

When should I use attach?

Use attach when you intentionally want the existing main-process streams, for example an interactive program started as PID 1. For a new diagnostic shell, exec is the appropriate operation.

See Docker exec and Docker attach.