Introduction

In a Dockerfile, WORKDIR does not behave like a temporary shell cd. It sets the working directory for all following Dockerfile instructions until another WORKDIR changes it, so "going back" simply means declaring a new working directory explicitly.

What WORKDIR Actually Does

Consider this Dockerfile:

1FROM python:3.12-slim
2
3WORKDIR /app
4COPY . .
5RUN python -m pip install -r requirements.txt

After WORKDIR /app, later instructions such as COPY, RUN, CMD, and ENTRYPOINT use /app as the current directory unless something changes it. Docker stores that working directory as part of the image metadata for subsequent build steps.

That is why WORKDIR is not something you automatically "undo." It becomes the new default state.

To Go Back, Declare Another WORKDIR

If you want the next steps to run from /, say so:

1FROM python:3.12-slim
2
3WORKDIR /app
4COPY . .
5
6WORKDIR /
7RUN ls

There is no special "return to previous directory" command. You just set the next directory explicitly.

Prefer Absolute Paths

Docker supports relative WORKDIR values, but absolute paths are usually clearer:

WORKDIR /app
WORKDIR /tmp

That is easier to read than chaining relative path changes and trying to remember the current directory state at each step.

RUN cd ... Is Different

Inside one RUN instruction, you can still use shell cd, but that change only lasts inside that one shell process:

RUN cd /tmp && ls

The next Dockerfile instruction does not inherit that shell state. Only WORKDIR affects the persistent working directory for later instructions.

That difference is one of the most common sources of confusion:

• 'RUN cd ... is temporary'
• 'WORKDIR ... persists for later Dockerfile steps'

Runtime Behavior Also Depends on the Final WORKDIR

The last WORKDIR in the image affects container startup too:

FROM python:3.12-slim
WORKDIR /srv/app
CMD ["python", "main.py"]

When the container starts, main.py is resolved relative to /srv/app. If that is not what you want, set a different WORKDIR later in the Dockerfile or override it when running the container.

Use Variables if the Path Appears Often

If the same directory appears repeatedly, an environment variable can help:

1FROM python:3.12-slim
2
3ENV APP_HOME=/app
4
5WORKDIR ${APP_HOME}
6COPY . .
7
8WORKDIR /
9RUN echo "Now at root"
10
11WORKDIR ${APP_HOME}
12RUN python -m pip install -r requirements.txt

This does not change how WORKDIR behaves, but it makes the file easier to maintain if the application path changes later.

A Better Mental Model

Think of WORKDIR as setting image state, not as running a temporary command. Once you adopt that model, the rule becomes simple:

• want a new default directory: use WORKDIR
• want a one-command directory change: use cd inside RUN

That prevents most Dockerfile directory confusion.

Common Pitfalls

• Expecting WORKDIR to behave like a temporary shell cd.
• Assuming there is a built-in command to "return to the initial directory."
• Using relative WORKDIR values and losing track of the current build directory.
• Forgetting that RUN cd ... does not affect later Dockerfile instructions.
• Ignoring the fact that the final WORKDIR also affects runtime command execution.

Summary

• 'WORKDIR sets the default directory for later Dockerfile instructions.'
• To go back, declare another WORKDIR, usually with an absolute path.
• 'RUN cd ... affects only a single shell command and does not persist.'
• The final WORKDIR also changes container runtime behavior.
• Clear absolute paths make Dockerfiles easier to understand and maintain.