How to Change Working Directory Command in Docker

Use WORKDIR in a Dockerfile to set the directory for later build instructions and the image’s default working directory. Use docker run -w /app to choose the directory for a newly started container process, or docker exec -w /app to choose it for a command launched in a running container. To navigate interactively, start a shell with docker exec and run cd there. These choices apply at different stages and scopes; changing one process or shell does not change every process in the container.

Understanding Docker working directories

A working directory is the starting location for relative paths used by a process. An image can define its own working directory, so do not assume that a container starts in /. WORKDIR sets a directory in the image configuration as well as for subsequent Dockerfile instructions. At runtime, docker run -w can select a different directory for that invocation. docker exec -w selects one for the newly launched command in an existing container.

Choose the mechanism that matches when you need the directory to apply: while building an image, when starting a container, or for a command or shell started later. A shell’s cd changes that shell’s current directory only; it does not alter the working directory of other processes or set container-wide state.

Set the working directory in a Dockerfile

In a Dockerfile, write WORKDIR /app before instructions that should use /app. For example, the instruction sequence can be expressed as FROM ubuntu:24.04, WORKDIR /app, COPY . ., and RUN make. This is Dockerfile syntax, not a shell script. The later COPY and RUN instructions use /app as their working directory. If the path does not exist, Docker creates it. A later WORKDIR changes the directory for following instructions.

RUN executes a build-time command; it is not a persistent way to set the working directory. For example, RUN cd /app changes directory only in the shell used for that RUN. A following RUN starts a separate instruction and does not inherit that shell’s directory. If commands need to share a directory change within one instruction, RUN cd /app && make runs both commands in the same shell, with make after cd succeeds. Prefer WORKDIR /app when later Dockerfile instructions should use that location.

Choose a working directory when starting a container

Use -w (or --workdir) with docker run to select the directory for the container’s initial process. For example, the syntax docker run --rm -w /app alpine:3.20 pwd starts a process in /app and asks it to print its working directory. The image name is alpine:3.20, and pwd is the command run in the container. Docker creates the selected directory if it does not exist in the container. This option applies to this container invocation; it does not edit the Dockerfile or rebuild the image.

The command above is an illustrative Docker command and is not accompanied by execution evidence in this packet. Run it on a host with Docker access to observe the result. A bind mount is only needed when the process must access host files; it is not required just to select a working directory. If mounting files, specify a host path and a container path separately, and make sure the container path is the one selected with -w.

Change directories in a running container

For a one-off command in an existing container, use docker exec -w /app my_container pwd. Replace my_container with the container’s name or ID and /app with the desired path. The -w option applies to that pwd process; it does not change the directory of the container’s main process or other commands.

For an interactive shell, start one with docker exec -it my_container sh, then enter cd /app at its prompt. Use bash in place of sh only if the image includes Bash. The directory change lasts for that shell session. It does not persist after the shell exits or affect other processes in the container. These commands require an already running container and are Docker-specific syntax; no Docker execution result is supplied here.

For a local shell illustration of how cd affects the current shell, use this example. It is unexecuted in the supplied packet and does not require Docker:

cd /tmp && printf 'Current directory: ' && pwd

This example runs in the shell where you enter it; it does not start or modify a Docker container. The same scope distinction explains why cd in an interactive container shell affects that shell alone.

Use WORKDIR for an image’s build-time and default directory, docker run -w for the initial process of a new container, and docker exec -w or an interactive shell for work launched in a running container. In each case, check which process or instruction will use the selected directory before relying on relative paths.